Agenda
See also: IRC log
Future Regrets: 4 June, jar; 4, 11, 18 June, LMM; 11 June, HST; 4 June, maybe, JK
NM: Last week's minutes?
HST: I have read and approved
RESOLUTION: Minutes approved as published
NM: If and only if you personally have a patent to exclude/disclose, you must do something
NM: Your company's patents are not relevant
JK: Can we discuss my action to
contact Sam Ruby wrt RDFa in HTML?
... should be quick
NM: Any admin questions:
<noah>
NM: JAR and I took an action to draft a starting point
<DanC> 0081 has Language versioning and evolution (focus on HTML), Web application state.
NM: I reviewed our discussion at the last F2F, and went over the state of issues and actions
NM: as well as TV's request to focus
on one or two key goals
... So in the above email, I've set out a small number of top-priority items, which will potentially get multiple sessions, if needed
... as well as lower-priority items destined for shorter/fewer sessions
NM: Two things in the big category at the moment:
<noah> * Language versioning and evolution (focus on HTML)
<noah> * Web application state
<noah> Henry, we should remind people that you are going to move forward the Dirk/Nadia URI story
DC: I'm always ready to talk about
"Language versioning and evolution", but lack confidence we will
make much progress
... Maybe LM will have something for us to work on
LM: I've produced an outline, and expect to have a fuller document in time for the F2F
<DanC> Versioning and HTML -- recap
NM: What concerns me most is whether we have any chance to get the HTML WG to take any help from us
LM: I am baffled by the conflicts around HTML5 as well, but
hopeful that if we can resolve the differences between the TAG's
work on version indicators and the HTML WG's intentions
... That will be of value
<DanC> (for ref: ftf mtg is 23-25 June; T-2 weeks is 9 June; T-1 week is 16 June)
JR: Not sure that insisting ahead of
time that we see our way clear to an impact isn't setting too high
a bar
... There are some questions we may be able to answer, and even if we don't move the HTML WG right away, it will be helpful in other ways
NM: We could invite Sam Ruby to join a telcon or even at the f2f -- what do people think
TBL: Sounds like a good idea
NM: Before, or during?
<johnk> before
+1 to before
TBL: Early sounds like a good idea
NM: I will reach out to Sam and see what we can schedule
JR: I'm quite optimistic that if we
prepare, we can have productive discussions
... I am prepared to put some time into this ahead of time
LM: Maybe JR can make some progress on my doc't while I'm away
<masinter> JR and I will talk on monday, i'll have something to give to him by then
<scribe> ACTION: JR to report back to the TAG on outcome of collaboration with LM [recorded in]
<trackbot> Created ACTION-272 - Report back to the TAG on outcome of collaboration with LM [on Jonathan Rees - due 2009-06-04].
NM: Anyone else to help?
DC: I will
LM: I would like to see the
Architecture for APIs question on our agenda -- we discussed the
Device APIs for Mobile chartering issue, and agreed not to engage
specifically there
... But rather than such specific engagement, more general engagement does make sense. For instance there are APIs throughout the HTML5 spec, where we maybe should get to grips with this.
<jar> +1 architecture for apis
<noah> I also think there's an interesting question of balance between APIs and declarative
<noah> Relates to rule of least power
NM: AM, are you interested in this? Could you pick this ball up from LM?
<johnk> I would be happy to help on this item
AM: I can try, but not sure what you want. . .
NM: Speak to as many people as you need
AM: I will talk to LM and come back to the group
JK: I'm happy to help
<scribe> ACTION: Ashok to carry forward framing issues around Archicture of APIs, with help from JK and LM [recorded in]
<trackbot> Created ACTION-273 - Carry forward framing issues around Archicture of APIs, with help from JK and LM [on Ashok Malhotra - due 2009-06-04].
LM: Consider the charter for GeoLoc,
which is about an API, there are APIs in HTML, then the Device API
--- there's a lot of it around, but our guidelines are mostly about
languages, and don't really give much guidance wrt APIs
... the issues about versioning are potentially different
... If the W3C Membership want us to start standardising APIs, it would be a good idea if we came up with some guidelines
<DanC> (I agree that we don't know much about how to do API standardization well, but I suspect the next step is to wonder around in the somewhat-darkness for a while; I wouldn't recommend doing architecture work based on a lack of info)
JK: We should have a look at how
Mobile and the Web interact now and going forward
... I have a presentation I've used before, that I'd like to share, which has a list of items which might help the discussion
NM: We'll do that
JR: What are next steps wrt agenda planning
NM: With this input, I will republish the list
JR: I don't feel this quite gets to
exactly what needs to be produced in the way of prep material
... do you have a schedule in mind wrt agenda planning?
NM: We'll talk
NM: We've discussed this by email and
briefly last week
... time to wrap this up and decide what to do
HT: I agree with the main thrust of the argument from Mike Kay, Noah and others that XML Schema 1.1 is clearly directed at the requirements given in the WG charter and addresses them well, and that the time to object to those requirements is passed. I do want to say something about uptake, because I think a lot of unsupported assertions have been made about this topic.
HT: Wrt XML Schema uptake, I did the following small experiment:
HT: Take the cover page of the Cover Pages, the longest-running and most carefully curated XML news site on the web:
HT:
HT: Look at the news items
HT: Tabulate their schema language usage
HT: 9 of the top 10 items include or depend on one or more XML languages:
HT: Items 1, 3, 4 (from OASIS), 2, 10 (from the W3C), 6 (from Oracle), 7 (from Microsoft), 8 (Web Services Test Forum), and 9 (from ISO) all define or depend on one or more XML languages specified via normative XSD schemas
HT: Item 2 also includes a (non-normative) DTD
HT: Item 9 also includes a (non-normative) Relax-NG schema
HT: I rest my case.
HT: Wrt to two of Rick's specific criticisms (lack of interop, and inappropriateness for text-oriented, as opposed to data-oriented, XML), I note that
HT: 1) wrt interop he falls back to only actually indicting data-binding tools, an area which the W3C tried to address with a WG but which lost critical mass w/o getting to REC---the spec. was not designed for this, and there are certainly aspects of 1.0 which don't lend themselves to data-binding easily, but those aspects are there in DTDs and Relax-NG as well!
HT: 2) wrt text-oriented XML, items 7 and 9 above are text-oriented, NDW has said the Schema 1.1 removes the main bar to using XSD for DocBook, and XHTML modularization switched to XSD (from DTDs) once XSD was available. My own experience with using XSD for a rewrite of XHTML Modularization was very positive.
HT: It's probably the case that a better, layered, XML language definition language could now be defined, based on 12 years' experience of XML itself and varying amounts of experience with at least four well-developed schema languages (DTD, XSD, RNG and Schematron). I think the time to start such an effort is in a year or two, when the financial climate is better and we've had some experience with XML Schema 1.1 and NVDL as well. Whether such an effort can succeed in practice, given the conflicting 80/20 requirements of different XML usage patterns, is an empirical question.
AM: I don't think it's worth arguing
about whether XSD is used or not -- it clearly is, and
heavily
... What we should do is look forward -- is there something we can recommend?
AM: Rick has a very specific request, that a profile of XML Schema be produced:
<Ashok>.
<masinter> I don't want to take this up. I think it's reasonable, in general, when members are unhappy with W3C work, for them to solicit interest from other members to do additional work to replace it
AM: HST thought it's too soon for this work --
I don't
... HST thought that it was perhaps not best done by the Schema WG -- I guess I agree
NM: What should the TAG do?
<DanC> (I wishes there were 3 to 5 XGs that sprung into existence to explore hypotheses such as Rick's)
AM: You would like us today to decide whether to recommend what Rick wants?
NM: In the first instance, what I
want today is a decision on whether we open an issue for this
... I agree with what HST said about the charter, while acknowledging DC's point
NM: Against the background of a workshop which responded to the databinding question by chartering the DataBinding WG, and pushed the 1.1 work forward
<DanC> (I find W3C Workshop on XML Schema 1.0 User Experiences
<DanC> ( )
<DanC> * 21-22 June 2005
<DanC> * Redwood Shores, CA, USA )
<noah>
<Zakim> noah, you wanted to point to Norm Walsh's note
NM: Wrt the question of whether we
should slow the progress of XSD 1.1 towards REC -- I strongly think we should not
... I found NDW's comments very much to the point in this regard:).
<DanC> (by the way... I have a huge XSD that I'm using for a lifescience project; what tool should I use to browse around it?)
<johnk_> DanC, if I use an XML "IDE" ever, it is
TBL: I react to the claim that everybody I know use schema by wondering how big the community that does actually is
<noah> I think Henry's evidence of Cover Pages spoke directly to the size and importance of the community
TBL: without doing a survey I don't see how we can tell
NM: Weren't those major vertical standards
HST: Yes
TBL: But what about private use
behind firewalls?
... We could go and ask the Members. . .
... There are certainly communities who just use Relax-NG
NM: All the evidence that I've seen is that The only question is the size of the difference -- that is, is XSD 1, 2 or 3 orders of magnitude more used than Relax-NG?
<masinter> There are places where different overlapping standards are more harmful than others, I don't think competing technologies are architecturally difficult
<DanC> (i note that the question of whether the TAG should consider this is now moot; we have considered it at length.)
TBL: That is true of the people you
know, the people in the Relax-NG community will pbly say the same
things
... but the other way around
<masinter> +1 to DanC's
<Zakim> timbl, you wanted to see that while Henry is not impressed by the suggestions that 'people' don't use schema, I am not that 'people' do. Clearly two largely disjoint communities
LM: There may be areas where
competing technologies are harmful
... I don't think this is such an area
... If there's new work to be done, the Members may or may not take it forward
... I don't think there's an architectural issue here
... If Rick wants to take this forward, he should do so in the way work normally gets taken forward, via the Process
<masinter> well, an issue that is worth TAG time on it
<Zakim> ht, you wanted to ask how the quote reflects a request for a profile
HT: Pass
At this point, the chair held a straw poll, to ascertain which TAG members would be in favor of opening a TAG issue relating to XSD 1.1. Only Ashok spoke in favor of the proposal.
NM: Wrt to whether the TAG should open an issue on
whether XSD 1.1 should be prevented from moving forward and/or
to explore ways to move schema work at W3C forward in a different way,
a straw poll revealed only AM in favour, so I rule that we will not open such an issue.
JR: I was hoping to write something
up here, I will forward some emails
... Trying to figure out what the TAG should be paying attention to here
... Both the TAG and the W3C are dancing around the API issue, which is a bit away from the WebArch home ground
... Wrt application architecture, we could either wait and watch, which is not a bad strategy, but it's not what we did about WebArch
<timbl> +1 to getting involved, no being passive, as this is an area which is important and inextricably linked to the web in general.
JR: I particularly like the Capability work, because it seems to me parallel in interesting ways to aspects of WebArch -- particularly as regards how things are named and how names are communicated
<johnk_> I think we would be "writing this down" too
<noah> Can someone help me put bounds on what "this" is? We've said we'd worry about APIs vs markup/declarative. There's a general question of security and isolation; there's a specific question of capability architecture. What's the proposed scope of TAG noodling?
JR: The ECMAScript security work is looking at a number of issues, in particular communication between mutually untrusting encapsulated apps
<DanC> (I suspect jar's "this" is capability based approaches to security vs. other)
<noah> Jar's email referenced Caja
<DanC> ka-ha
JR: The Caja example illustrates their approach to this
<DanC> there's one in microsoft labs too
<noah> From JAR: Web app security - Caja demo email
JR: Secure cooperation in javascript containers: four or five approaches, all coming together to standardize at ECMA
<jar> Cajita, ADsafe, Javaranda, and Dojo Secure are coming together via Ecma.
JR:I think that email closes my action
<Zakim> DanC, you wanted to see if I can reconstruct a discussion with tlr where present course and speed will lead to GET-based links becoming regarded as unsafe
<masinter> is this an area where W3C should have a workshop? rather than a TAG agenda item or issue?
<masinter> this is the "origin" header issue?
<johnk_> yes, related to Origin header
<noah> That's the best XSRFF explanation I've heard (though it's not scribed yet)
DC: Consider you're logged in to a
gaming site, you have lots of treasure, you go to another
(black-hat) website which does a POST to the gaming website in an
onload method
... I was surprised this (a POST) was allowed effectively inside a GET
... The games website has a work-around, but it is a real pain, because the workaround requires a nonce, so it can't be static
... This is promoting a view that links are not safe
<jar> zooko's triangle.
JR: zooko's triangle is an argument that the security of links is constrained
DC: I'll try to reconstruct the connection
<DanC> ACTION: DanC to see if I can reconstruct a discussion with tlr where present course and speed will lead to GET-based links becoming regarded as unsafe [recorded in]
<trackbot> Created ACTION-274 - See if I can reconstruct a discussion with tlr where present course and speed will lead to GET-based links becoming regarded as unsafe [on Dan Connolly - due 2009-06-04].
<Zakim> ht, you wanted to ask if he should close 204
<DanC> close action-204
<trackbot> ACTION-204 Talk with Mark Miller about web app security and report back closed
JR: There have been efforts to get some coordination with W3C on this -- keep your eyes open for ECMA-W3C coordination opportunities
<DanC> nov meeting sounds familar... looking...
NM: I'd like to see this as a f2f focus
<DanC> hmm... rather "The AJAX Experience, Boston, September 14-16"
NM: DC said "Seems weird that you can
do a POST from a page you do a GET for" -- but doesn't that happen
all the time?
... When I go to e.g. Yahoo it's a form, I GET it, then I POST to log in
NM: How is that different
<jar>
HT: But in DC's example, you didn't
do anything, the POST happened inside an
onload of the page you
did the GET for
NM: Not so different?
DC: Seems different to me.
DC: I see an AJAX meeting in Boston
14--16 September, which was a possible IETF-W3C cooperation
opportunity. . .
... Maybe not ECMA -- maybe that's November
<johnk>
JK: There is about a Creative Commons
spec. about how to use RDFa in XHTML -- they define a way to use a
CURIE in a 'rel' attribute
... I emailed Sam Ruby, Mark Nottingham and Ben Adida
... Ben replied with some details, Shane McCarron gave more information about RDFa in XHTML
<DanC> the ccREL spec seems to be
JK: The XHTML Mod. spec. seems
unclear about how/whether CURIEs are supported in 'rel' attrs
... The larger issue is of course how RDFa might be integrated into HTML4 and/or HTML5
... Shane McCarron has sent a proposal about HTML4 integration to the HTML list, thread continues also from
... The use of CURIEs at all is also not settled -- MNot's Link Framework draft doesn't provide for CURIEs at all
... I don't think there's any specific followup required
<johnk> here's Shane's proposed RDFa in HTML 4 proposal -
DC: CURIEs are the small end of the issue
<jar> I'm not too worried about lack of CURIEs in Link: header. Seems silly as that's protocol level. Purpose of CURIEs is to make RDFa easier on the eyes, easier for manual editing.
DC: CcREL is about allowing access to
e.g. my pictures for reproduction
... There are a number of actors here, ranging from 0 (WGs chartered to change HTML4) to 2 (WGs chartered with some responsibilitiy for text/html)
NM: Next steps?
JK: We haven't been asked to do anything by anyone
NM: I have an action to reach out to him wrt [xyzzy]
JK: I don't see any actions at this point
DC: There's a microdata proposal from Ian Hickson, which is intended to meet the CcREL requirements, w/o using RDFa (or namespaces?)
<DanC>
<DanC> <img itemprop="image" src="google-logo.png" alt="Google">
DC: HST, you interested?
HT: Yes, I will look at this if I
can
... I accept to shepherd ISSUE-54
NM: Please clean this up as best you
can
... Adjourned
<DanC> darn; lost henry to dinner; wanted to get his permission to update tracker due dates for his action
sure
<DanC> ok... I'll move them back a couple months except the urns-and-registries one
<DanC> ACTION-113 due 1 July
<trackbot> ACTION-113 HT to a) revise composition.pdf to take account of suggestions from Tim & Jonathan and feedback from email and b) produce a new version of the Elaborated Infoset finding, possibly incorporating some of the PDF due date now 1 July
<DanC> ACTION-239 due 1 July
<trackbot> ACTION-239 alert chair when updates to description of xmlFunctions-34 are ready for review (or if none made) due date now 1 July
<DanC> ACTION-232 due 1 July
<trackbot> ACTION-232 Follow-up to Hausenblas once there's a draft of HTTPbis which has advice on conneg due date now 1 July
<DanC> ACTION-231 due 1 July
<trackbot> ACTION-231 Draft replacement for \"how to use conneg\" stuff in HTTP spec due date now 1 July
<DanC> ACTION-33 due 1 June
<trackbot> ACTION-33 revise naming challenges story in response to Dec 2008 F2F discussion due date now 1 June
<DanC> I think we closed this one today:
<DanC> ACTION-271?
<trackbot> ACTION-271 -- Noah Mendelsohn to work with jar to draft strawman agenda for F2F -- due 2009-05-28 -- OPEN
<trackbot>
<DanC> ACTION-265 due next week
<trackbot> ACTION-265 Work with Larry, Henry to frame technical issues relating to the vairous overlapping specs. about URIs, IRIs and encoding on the wire due date now next week
<DanC> ACTION-23 due 1 July
<trackbot> ACTION-23 track progress of #int bug 1974 in the XML Schema namespace document in the XML Schema WG due date now 1 July
<DanC> ACTION-270 due 1 June
<trackbot> ACTION-270 Provide additional material for review at F2F for Issue 41 due date now 1 June
<DanC> ACTION-254 due next week
<trackbot> ACTION-254 Send email to www-tag announcing issue-63 due date now next week
<DanC> ACTION-261 due next week
<trackbot> ACTION-261 Followup with Mark Nottingham and Lisa D. regarding Adam Barth's sniffing draft due date now next week
<DanC> ACTION-244?
<trackbot> ACTION-244 -- Noah Mendelsohn to plan June TAG F2F -- due 2009-05-19 -- OPEN
<trackbot>
<DanC> noah, do you want to do anything more with action-244?
<noah> Leave it open, it's just a memory jogger to me, though at this point I tend not to forget about it anyway. The date should be pushed one week at a time :-)
<DanC> ACTION-261: spoke with Lisa about an upcoming BOF
<trackbot> ACTION-261 Followup with Mark Nottingham and Lisa D. regarding Adam Barth's sniffing draft notes added
<noah> I'll do it
<DanC> action-244 due next week
<trackbot> ACTION-244 Plan June TAG F2F due date now next week