See also: IRC log
<ht> Scribe: Henry S. Thompson
<ht> ScribeNick: ht
(Dave O, TVR to attend by 'phone late afternoons)
SW: Scribe schedule: M p.m. NM; T a.m. RL, T p.m. NW; W a.m. DC
RESOLUTION: to approve minutes 13 Sep
<DanC_lap> (I couldn't find a decision to meet in November when I looked, actually. I suppose it doesn't matter much.)
SW: We have an f2f booked for November, but no venue or date for the next one
NM: DO has suggested Feb/Mar in Vancouver
DC: I am renewing a bid for Venice -- Massimo Marchiori would host
TBL: an idea: Monterey, adjacent to TED 29/2--1/3
HT: 3--5 March I have to be in
Tokyo, travel either side
... but my term ends before then
TBL: How about 26-27 Feb?
... in Vancouver?
SW: HST and TVR (elected); NM and DC (appointed) terms end 31 Jan 2008
<scribe> ACTION: Stuart to pursue Feb Vancouver hosting offer via WBS, pbly for 3 days [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action01]
<Rhys> > draft
RL: I've gotten lots of good
feedback on this
... Both Pat Hayes and Roy Fielding have gotten involved
... The problem in part is terminological -- the distinction between HTTP 'resource' and WebArch 'resource' hasn't been well drawn
TBL: Roy Fielding, either in his thesis or the HTTP spec., wasn't particularly formal about terminology
RL: What I mean by HTTP:resource is the definition in the HTTP spec. of 'resource'
NM: Some of those produce 200 when you do a GET, and sometimes you get a 303, and then whether the URI identifies a resource or not is unclear
<DanC_lap> http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.3 [[ resource A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways. ]]
RL: In section 1.3 Terminology we have a defnition of a network data object or service
NM: Does this cover only http: URIs?
NW: No, section 3.2 makes clear it covers URL, URN, ... -- any scheme
RL: So I was trying to define two terms in the draft -- I'm using 'web resource' for the meaning from WebArch and 'web presence' for the HTTP/1.1 meaning
HST: What about the original definition of "a resource is anything that can be named by a URI"
SW: That's in the URI spec.
TBL: I'm not so interested in old
definitions, because they were often not framed in very strict
... The distinction between inf. res. and res. which we articulated in WebArch was hard-won, and does have the crispness we need
RL: So I think we left something
out of WebArch, which is what I've called 'web presence', which
is what responds e.g. 302 when you GET a non-inf. res.
... This is what I've called a 'web presence'
NM: What about 404?
RL: That's the one thing that's not a web presence, it's the lack of one
NM: What kind of thing is it?
DC: Is there a definition in the draft?
RL: No, not really -- examples and discussions
NM: It feels like a state of being
RL: That's sort of right -- it could be a piece of code, or some server configuration -- it's the result of someone _doing_ something so that doing a GET on a particular URI will not respond 404
SW: It's an aspect of web
... Partly addresses Pat's complaint of the distinction between what you access to find out about Mars and Mars itself
... Pat wants us to distinguish more carefully between access and identify as operations/terms
RL: Looking for an architecture level description of what someone does when they mint a URI, whetehr
<Zakim> ht, you wanted to follow up on 'what someone does'
<Zakim> DanC_lap, you wanted to ask that we please tell the straightforward story of "doc#term means whatever term refers to as used in doc, by analogy to one paper importing a term by
HST: I really like this idea of what it is someone does, once, so that thereafter something which used to produce a 404 now produces something else (useful)
DC: I really want this document
to focus on the simple questions of what doc#term means
... and how people should choose URIs
SW: The original motivation was
RL: to take the short email Roy Fielding sent about our closing of httpRange-14 and write it up in detail
DC: Then how can the issue be closed?
[unminuted process discussion]
<DanC_lap> ("core issue decided" is just silly if what's written down doesn't satisfy the community)
<DanC_lap> actually, http://www.w3.org/2001/tag/group/track/issues/28 fragmentInXML-28
SW: What issue should we address a) the 300 responses and b) the # issues under?
TBL: I think the # question is
important -- there are lots of uses of it both in RDF and HTML
and there's a lot of confusion and misunderstanding
... We can and should write a finding to explain how this all works, to help the communities which are struggling
<Zakim> Noah, you wanted to say we shouldn't talk too much about the deployment mechanics
<DanC_lap> (issue 57 is somewhat timely w.r.t. the WebAPI XHR work)
NM: I am worried that the draft
is a bit too broad -- not clear to me what the focus was
... a lot of stuff about things you might like to learn about interacting with the Web
... but it didn't really work for me, a mixture of things that are right, things that are not quite right and things that are wrong
... It needs a set of goals, to focus discussion on how the document actually addresses the goals
RL: I had a set of goals, which I guess didn't come through -- focussed on explaining what it could mean to interact with non-information resources
NM: I'm worried that the overlap with the existing IETF RFCs isn't managed well -- in particular, 2616
RL: Well, we did say in our SF meeting that we would include the response codes
<Zakim> ht, you wanted to add indirection identification to the pile
<DanC_lap> (hmm... indirect identification... I'd like more clarity on that, though I can imagine it would cost a lot to get there)
<Zakim> DanC_lap, you wanted to suggest looking at redirections in the XHR spec
HST: I hope we will include indirect identification in any attempt to provide an overview about designing URIs, including when to use #
<Norm> Yes, 303 is weak practically, if not theoretically
DC: There is an opportunity, in the context of XMLHttpRequest, to revise the way redirects are exposed through standard library APIs
NM: So you're saying the code reflects a narrower understanding of how the Web should be working, and the opportunity is here to try to fix this
DC: For example, if you have a relative URI to resolve against a redirected base
TBL: SemWeb is worrying about that
<Zakim> Norm, you wanted to say that in retrospect, we shouldn't attempt to redefine the return codes
DC: GRDDL has a 5-page appendix, which says, briefly "Resolve against the result of redirection"
NW: It is a mistake to try to redefine what the response codes mean
NW: The most we can say about 303 is that we are using an existing technology in a particular way
RL: I put section 4.3 to implement what I understood the group to be asking for, so we could decide if we really mean it
NW: Right, and now that I've seen it I think we were wrong, and it should come out
<Zakim> timbl, you wanted to ask whether Dan wan ted a tutorial (rather than judgement) about hash, and to suggest we do worked examples in HTML and RDF.
NW: We can say we use it in such and such a way, but we can't say what it _means_ -- that's for the RFC
TBL: An issue on what # means, or a tutorial to tell people?
DC: Issue 28 is good enough for me (# in XML)
TBL: Not good enough for me -- in a tutorial, I can say using Planets#Mars to identify Mars can work w/o ever doing a GET, and someone responds "Without doing a GET, how do I know what the media type is, w/o which I don't know what a fragid means"
NM: I didn't understand your take on that until you explained it to me at a f2f, roughly, that in the _absence_ of a media type there are general principles I can appeal to
DC: It's best if you have a media type and a resource and that gives the same answer, but you can live w/o it
<DanC_lap> DC: you can get information about what a URI identifies from various places; it's best when they agree
TBL: Working here on WebArch fed well into the redraft of the URI spec -- maybe the same thing would work for the proposed redraft of the HTTP spec. . ..
SW: How about the Cool URIs for
the SemWeb document -- that seems like a good start on a "how
to design URIs" document
... Any progress on ACTION-43, TBL?
<scribe> ACTION: [WITHDRAWN] on Tim Berners-Lee to Find the paper that he annotated on the plane (and transcribe comments on "Cool URIs for the Semantic Web"). ACTION-43 [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action02]
SW: # w/o content-type? You can work backwards from what must have been the minter's intent
<Zakim> DanC_lap, you wanted to note "cool URIs" is headed for /TR/
DC: The SemWeb Cool URIs spec is
officially believed to be on our queue, for TAG review before
it goes to REC
... It's getting exposure, and we should take on reviewing it
SW: I have sent reviews on behalf of the TAG on an earlier draft
DC: So we should be reviewing the new draft, to see if they did what we asked
<DanC_lap> (I find http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/ 9.8.2007 )
<DanC_lap> (sort linked from http://www.w3.org/2001/tag/group/track/actions/43 )
<DanC_lap> ( I also find https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html ... date pending... )
<DanC_lap> 14 Feb
<DanC_lap> 14 Sep 2007 , says HTTP last-modified
Last line says "1.1 Revised Version 9.8.2007. Changes based on TAG review."
<Noah> Asking about http://lists.w3.org/Archives/Public/www-tag/2007Jun/0075.html
<Norm> I found Dan's suggestion of projecting it and doing a group review somewhat appealing
SW: ACTION: TBL to review the 14 Sep draft of the Cool URIs for the SemWeb document on behalf of the TAG and bring the comments back to the TAG
<Noah> Was it officially on behalf of the TAG? Ah, first signature says from Stuart, 2nd says Stuart for the TAG. Sorry, missed that.
NW: I will try to review it, but I also like the idea of a group review from a projected view
SW: Shall we carry this over, or
stick with the agenda
... that is, we could pull the review of action statuses forward, to give us time tomorrow for a projected review. . .
SW: So RL would like us to use some of 'his' time to look at the SWCoolURIs doct, in case it influences the treatment of his draft
NM: Let's not leave w/o coming back to Rhys's draft for disposition
TBL: The discussion of URI/URL in the intro is at best misleading -- they shouldn't use URL at all
DC: I think this speaks to the audience
NM: Doesn't the latest RFC move away from URLs?
DC: Yes, that's what this para.
... deleting URL won't help
NM: I think the history of this should be explained here
<timbl> 1. "At the same time, web documents have always been addressed with Uniform Resource Locators (URLs). URIs and URLs share the same syntax, every URL is also a URI. "
<timbl> The distinction between URLs and URI is not helpful. The term "URI" should be used throughout. This discussion has I suspect prompted the rather confused track "What happens if a URI is also a URL?".
<timbl> 2. "On the traditional Web, URIs were used primarily for Web documentsâ€”to link to them, and to access them in a browser. In short, to locate a Web documentâ€”hence the term URL (Uniform Resource Locator). The notion of resource identity was not so important on the traditional Web, a URL simply identifies whatever we see when we type it into a browser."
<timbl> This uses the term URL, but suggest identity was not important ... it was important.
<timbl> change to maybe
<timbl> "On the traditional Web, URIs were used primarily for Web documentsâ€”to link to them, and to access them in a browser. In short, to identify a Web document, such as <http://example.com/about> or a hypertext acnhor within a document such as <http://example.com/about#staff>. With the semantic Web, URIs are used to identify arbitrary things such as people, proteins and calendar events.
<Noah> Note that I suggested during the discussion that it might be helpful for them to explain that the recommended terminology was changed in RFC 3986. URL used to be an appropriate term, now URI is preferred.
RL: They use URIs in the titles of sections, and URLs everywhere else
DC: I prefer they dispose of URL in the introduction, and use URI througout
NM: Or put in an appendix to explain the history
General discussion leading to an agreed first comment in TBL's draft [to be attached]
TBL's second comment: Identity was always important
DC: Google does lots of canonicalisation because the value of cache hits is high and the cost of conflating two actually distinct resources is low
<Stuart> FYI... my comments on the earlier draft are at: http://lists.w3.org/Archives/Public/www-tag/2007Jun/0075.html
SW: Section 2 doesn't really address the reference/resource distinction
NM: I'm concerned with the 'everything' in that section
TBL: I don't think it's all that misleading, this is a tutorial, I think it's OK
TBL's second proposed edit agreed as written
<DanC_lap> bug: "Content negotiation [TAG-Alt] is often implemented with a twist: Instead of a direct answer, the server redirects to another URL where the appropriate version is found:"
<DanC_lap> no, that's not content negotiation
HT: is 302 the one that means "fix the source link"?
<DanC_lap> DC: hmm... maybe redirects based on Accept: are a form of conneg
DC: Well, maybe if they're choosing a redirect based on headers it _is_ conneg too
<DanC_lap> oh, just change "the HTML..." to "the content of the document in HTML in English"
<DanC_lap> hi DO... we're poring over https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html
Further discussion of how strong to make TBL's comment 4 on the conneg/redirect para
and of the cost (theoretical and practical) of round trips
<Noah> From our alternative representations finding: http://www.w3.org/2001/tag/doc/alternatives-discovery.html#id2261787
Wording of TBL's comment 4 agreed
<Noah> With that same URI, use HTTP content-negotiation, along with the correct HTTP VARY headers to serve up the appropriate representation at access time. Ensure that the VARY headers capture the right parameters that were used to choose the representation that is being served — this is important for correct behavior when using cacheing proxies.
<Noah> As an alternative to the previous step, arrange for the server to generate an HTTP 302 (Found) redirect to automatically serve up http://example.com/ubiquity/representation_i when http://example.com/ubiquity is accessed by user-agent_i.
<DanC_lap> (we started ~30min later than the agenda called for; the agenda calls for lunch at 12:30. I'm starting to feel lunch-y)
Discussion of the 301/302 difference, and the fact that browsers (incorrectly) treat them the same
TBL: There's a security argument for this -- not letting the user be misled about "where they are"
Discussion of SW's comment on the first para of section 3
SW: OK, I'll back off, but I do maintain that not all use of e.g. 303 are by definition uses of the Semantic Web
<DanC_lap> (hmm... I wonder about using "hypertext web" rather than "traditional web")
HST: I think that _historically_, that is, before the SemWeb was thought of, that http: URIs were _always_ used to identify what we know call information resources.
<DanC_lap> (hmm... "We call these things resources" suggests there are things other than resources, which there aren't. noodling on alternatives doesn't yield much, though.)
<DanC_lap> for the record, I abstain from adding http: in there too, norm.
DC: Shall we carry this forward offline?
<Stuart> ACTION: Norman review Cool URIs for the Semantic Web [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action03]
<trackbot-ng> Created ACTION-46 - review Cool URIs for the Semantic Web [on Norman Walsh - due 2007-09-24].
<ht_> [break for lunch]
<Stuart> trackbot-ng, status?
<Stuart> trackbot, status?
<DanC_lap> trackbot-ng, status
<Stuart> ACTION: Tim Review the 14 Sep draft of the Cool URIs for the SemWeb document on behalf of the TAG and bring the comments back to the TAG [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action04]
<trackbot-ng> Created ACTION-47 - Review the 14 Sep draft of the Cool URIs for the SemWeb document on behalf of the TAG and bring the comments back to the TAG [on Tim Berners-Lee - due 2007-09-24].
<dorchard> I can dial in now. Apparently I'm awake for the duration...
<Noah> scribenick: Noah
<scribe> scribe: Noah Mendelsohn
date: 17 September 2007
<scribe> chair: Stuart Williams
<scribe> agenda: http://www.w3.org/2001/tag/2007/09/17-agenda
<dorchard> wanders off to review Noah's latest note..
SW: Need to ask whether as a result of this morning's discussion we can give Rhys guidance.
HT: Don't think so. We didn't make it into the pertinent parts of the Cool URI's document.
SW: Yes, seems unlikely we can
get far enough while Tim's still with us.
... OK, we might come back to this at 14:30 UK time, otherwise after Cool URIs review is completed.
<ht> Dave, use that code and we'll join you shortly
<ht> ht has danC_lap, Noah, Norm, Rhys, Stuart, timbl
SW: Where should we go with this?
HT: On last telcon, my review of XHTML modularization concluded that with respect to distributed extensibility, XML Schema Substitution groups, particularly as provided in Schema 1.1, are just what they need. Remind me, what's the motivation for this issue again?
SW: Had some roots in class attributes, profile attributes (possibly deprecated in HTML 5), microformats, etc. If the values for these aren't URIs, or don't get you to URIs, you can't "follow your nose" on the Web.
DC: I had raised an issue
relating to standardized name values. When Microsoft and
Netscape were arguing about the Marquee tag, we said short
strings were bad. Now we act like in microformats it's OK.
Maybe it's because there's more of a consensus process around
... Then people ask "what about collisions". I think microformats answer is "not a serious risk". To some extent that's true. And there the conversation tends to stop.
... Comes up somewhat with respect to new URI schemes. Stopping to ask IANA when you're grinding code isn't something people feel motivated to do. Hard to know how to motivate people.
... There's a Facebook ML (FBML) proposal from Facebook that's mentioned in a Sam Ruby post. Was discussion about distributed extensibility with Ian Hickson about SVG etc. in HTML 5. Ian says: they'll be there. The pushback is that things like SVG were the result of relatively centralized definition.
... HTML group seems to take position that these things should shake out, and then get integrated into HTML as the community settles on them.
HT: Is this an issue people are still prepared to discuss, or are positions pretty well set.
<Zakim> dorchard, you wanted to say that I think microformats does "values", are *nice* guys, and fly below the radar but technically no different
DO: The microformats answer is
only OK until there is a collision. The multimedia folks did
hit a collision and wrote up an interesting posting on
... That's different from the <marquee> case, because attribute values seem less scary than element names. Also, everyone involved seems like nice guys; less concern about corporate agendas.
<DanC_lap> (the difference between element names and class attribute values is that class attribute values were open to the user/author, and element names were reserved for standardization)
DO: So, this seems to fly below the radar, but technically attribute value squatting is no different than element name squatting. There really isn't openness at microformats.org
<Zakim> ht, you wanted to mention XPointer registry
HT: As a result of discussion in
this forum a long time ago, we did in the end implement a
registry for XPointer schemes at W3C.
... This lets you construct a URI from the short name to get the information you need.
... This an example of a middle ground option.
NW: I think that's only the right answer if you own the space in which the name goes. Probably not right for class attribute.
HT: Yes, but might be for roles. Why couldn't microformats people do that?
NM: Because they don't get to say what goes in my class attributes.
TBL: I happened to use rel="chapter" in some of my design issues book, so RDFa guys produce bogus triples when pointed to my stuff.
NM: that's related to the
long/shortname issue, but the real problem there, as with
microformats, is grabbing ownership long after the first
... So, distributed extensibility is an important issue. Deciding that certain attribute values have specific meaning years after documents have been deployed is a related but ultimately different issue.
NM: First come first serve doesn't give you much quality. One of my concerns about microformats is that in 20 years we'll all know that class="phone47" is the right way to do phone numbers, because the first 46 cuts weren't right.
Dave - please type in what you said...I had trouble getting it for the minutes. Thanks.
SW: Do registry based systems meet the need.
<dorchard> Now here's an idea. Microformats should define a versioning strategy that includes version #s in the value (structured attributes)
HT: Yes, it's not centrally managed.
DC: Huh, of course it is.
HT: I'll try again. Something that's automatic and first come/first serve, because anyone can initiate the grabbing of the name.
<dorchard> Then they say if you see "phone" or "phone1xyz" then they are compatible.
<dorchard> if you see "phone2xyz" then they are version 2 of the phone and all v2 phones are compatible
HT: Aren't dns names a good example?
NM: Well, there have been ICANN problems.
TBL: Well there are lists, trees,
etc. At least trees have delegation. Graphs remove that
... I think a tree is right for DNS, because sometimes you need some control. Nobody's done internet with guids on everything.
HT: If you want global uniqueness, a registry is as distributed as you can get.
DC: Large random numbers.
<Zakim> DanC_lap, you wanted to bring up recent Atom
<dorchard> I previously said "adding the equivalent of ns prefix to microformats may be too complicated, and the microformats folks probably wouldn't change what they did"
DC: Tim Bray blocked about Atom interop problems and David Megginson suggested that XML Namespaces were an example of premature standardization.
<DanC_lap> comment From: David Megginson (Sep 14 2007, at 17:33)
<DanC_lap> "in retrospect, we got too far in front of implementors' requirements and delivered a spec to solve problems someone might have some day in the future, instead of problems people actually had at the time."
HT: Yeah, one of the RDF tools assumes that xsd: is bound to the 2001 XML Schema namespace URI. I used it for something else this week and the tool just blew up.
<DanC_lap> <link rel="openid.server" href="http://openid.example.com/">
DC: Sometimes you see rel="openid.server". Like prefixing your emacs functions with your initials.
HT: Emacs has no package system.
<Zakim> dorchard, you wanted to say that planning for the future will always provoke a response of "that's not a problem why should I do it now?"
NM: I think everyone more or less agrees about the technology choices, it's getting people to see that the use cases matter.
DO: Getting people to plan for
the future, as with versioning, is hard.
... Microformats folks feel that "I don't have a problem now."
... You can generalize that to try and figure out when you're going to have trouble. It's easy to see in Java that you will.
... Less obvious for class attributes.
<DanC_lap> (I'm curious about the cost/benefit in practice with java using DNS for package names... it avoids some conflicts, but it motivates some renaming when companies move in DNS space, I gather. I'm curious about actual experience)
<ht> HST found it a royal pain
DO: Dave Megginson may say namespaces was premature. It's not perfect but it's been effective in giving the community something to solve the problem.
SW: We need to talk about the "follow your nose" aspect.
<dorchard> On the "follow your nose" rationale for using URIs, I think most folks figure that search engines solve that problem..
DC: We used to joke about how, before Google, it implied that everyone would have to talk to everyone.
NM: How does that work?
DC: Google registers that all.
NM: That's not everyone talking to everyone, it's everyone talking to Google.
<Zakim> ht, you wanted to consider the Python example
TBL: Noah's right. Everyone talking to everyone is n-squared. What you're describing is a notice board, which is order n.
HT: Well, I just tried looking at
my own favorite DTD, which has a class="code". So, I took Dan's
advice and Googled them. Lo and behold, there are lots of them.
How do I know if they're significant?
... It's not a usable notice board. How do I use it?
DC: You just did. You told me it's "all over the map".
HT: I can't tell if I'm openning myself to the problem Tim experienced, which is what Tim reported, I.e. that someone will infer the wrong semantics from my document.
Henry takes some time to look for class="vcard" in Google.
HT: If I wanted to put some of this in a TAG finding, I couldn't.
<raman> Raman, signing in from the bus to work
DC: It's economics. 10 years ago, the cost of doing the search was higher.
<raman> Please email me the dialin and access code, can dial in once I get to work (about 60 minutes from now
HT: Nothing was done to help the emacs community. Python didn't have a package mechanism to start, but around v1.4 or so Guido decided to offer an (optional) package system.
<raman> I think most of the pushback against namespaces and packaging in the html community is a consequence of using namespace URIs to achieve the end-result --- the pushback is "syntactic not semantic".
<raman> Notice that no one pushes back against greasemonkey scripts introducing a namespace
<raman> Noah, none of what you typed about the conference code made any sense to me.
NM: The community that's vulnerable to collisions is very different when I'm important some emacs macros than when someone runs a tool over the Web and stumbles on Tim's document.
<raman> OK, I'll use zakin with our usual code when i get to work
DC: Grounding packages in DNS can be a pain if a company gets bought.
NM: The Norm is you live with the old package names.
<raman> Also, given their syntactic ugliness, xml namespaces do far less than they promise on the surface no nesting for instance (not that I want nested namespaces -- that was a disaster in Common Lisp).
RL: There are tools that will just do it for you in Java.
<DanC_lap> redimport, I think
NM: Again, remember that there's usually a programmer there, knowing what they're doing when you use a Java package. Anyone at all can find Tim's documents on the Web.
<DanC_lap> (this bumps into all my noodling and bookmarks on software installation)
TBL: there are tools that let you do some automatic import in Python
SW: Are we ready for our technical plenary session?
DC: I think the rubber hits the road when we talk to HTML 5, openid, groups, etc. I'm OK if this sits in the someday pile until the plenary.
SW: We've had offers from Tim,
Noah, Dan, and Norm.
... Dave, you pick what you need.
... Dave, are you moderator?
DO: I've proposed, nobody pushed back. I'd be ok if someone else moderated after I brought people together.
NM: Dave, we had talked about asking you to host a face to face in or near Vancouver Tues-Thurs Feb 26-28. OK?
<ht> Uncaught exception: Permission denied to call method XMLHttpRequest.open
<ht> zakim +0 is ht
<scribe> ACTION: [DONE] Henry S. Thompson to Review XHTML Modularization (http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705/) ACTION-15 [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action05]
HT: I said on the call that
substitution groups were a good bottom up extension mechanism,
but a bad top-down modularization mechanism. They're not that
good at helping you to share work. For example, sharing between
XHTML basic an other versions.
... A good system should help you maintaining the versions as bits change.
... I've concluded that what I said was false. You can in fact achieve good top down sharing.
... The simplest and most universal way, we be to have one file per element. They already have >50 files for 80 elements, so they're nearly there (though they might not be fully conscious of that).
HT: 30 second version. Substitution groups are bottom up. The only thing that determines whether <a> is allowed is in the definition of <a> itself. So the easiest way to determine whether <a> is in your language, is to include only the file with the def. of <a>. One can do better. Intuition is I could reproduce what they have, but I haven't proven that.
NW: For what it's worth, the Docbook RelaxNG schema works in a very similar style.
SW: You have an action item.
<Stuart> trackbot-ng, status
HT: I want a new one.
ACTION-16 on David Orchard to Incorporate the NVDL text into the findings. - due 2007-09-27, open
SW: Action continues.
<scribe> ACTION: Noah Mendelsohn to draft a blog item for review and, pending creation of a TAG blog mechanism, post it (ACTION-28) [CONTINUES] [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action06]
SW: Continues, pending availability of blog
DC: Is the blog on today's agenda.
<ht> ACTION: ht to produce an exemplary implementation of XHTML Modularization using substitution groups for both bottom-up extensibility and top-down modularity [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action07]
<trackbot-ng> Created ACTION-48 - Produce an exemplary implementation of XHTML Modularization using substitution groups for both bottom-up extensibility and top-down modularity [on Henry S. Thompson - due 2007-09-24].
<Norm> trackbot-ng, status
<dorchard> A link to the announcement of latest editor's drafts should be on the agenda and the issue page:
<scribe> ACTION: on Stuart Williams to complete review of terminology section of of 4 July versioning draft. ACTION-35 [DONE] [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action08]
SW: I posted a review last week. Dave, did you see it.
<Rhys> > Stuart's review
DC: You said:
"Defn: A *Language* ..."
"Defn: A *Language* consists of a set of admissable text;
DC: Why did you want that
... I thought the original definition was OK.
SW: At least note that I have
done my action.
... I didn't see the terminology much used in the strategies.
NW: I had the same comment on use of terminology in the XML section.
<DanC_lap> http://www.w3.org/2001/tag/doc/versioning-strategies#forwardsCompatible 2.2.2 Forwards Compatible
<DanC_lap> DC: we talked about 2.2.2 strategies before; I'm interested to see how the recent changes deal with it
DO: I asked Noah to look at
2.2.2, he had problem with GPN. He pointed out that the GPN
isn't right because it doesn't deal with reduction.
... Noah agreed that expansion is the majority of the cases, but suggested that we be clear in an intro, and proposed some text for an intro.
<DanC_lap> (sounds like "requires" is too strong, since later it says SHOULD; maybe "motivates")
<Norm> DanC_lap asked for an example of terminology problems; compare "component" in the terminology section with "component" in the XML document.
DO: Noah also brought up that
that if we're just doing extension, then the GPN is a
... That's why I had said SHOULD in the GPN, to account for reduction.
... Maybe it's not a GPN, it's an axiom. But I feel it needs to be bolded.
... I also posted a couple of lengthy articles on my blog.
DO: Marc de Graauw also posted some material on www-tag, but unfortunately I haven't yet reviewed it in detail.
<DanC_lap> (good question: who is the GPN aimed at? surely language designers)
NM: That's mostly a good summary. I wonder whether this isn't really trying to say "extensible languages are good, consider creating one"
<Zakim> DanC_lap, you wanted to observe that "Any Language intended for forwards-compatible versioning SHOULD have extensibility." seems odd... the definition of language doesn't seems to
DC: I think having extensibility
... I think having extensibility means it has redundancy?
NM: Yes, that's how I'd like to do it!
DC: But is that what Dave wrote. I'm trying to remember the definition. It seems to say that a language is extensible if there is redundancy.
TBL: Yes, spare syntax.
<Stuart> [Definition: A language is Extensible if the syntax of a language allows information that is not defined in the current version of the language.].
<Stuart> from http://www.w3.org/2001/tag/doc/versioning
DC: There no processors in the
... In part 2 it says: " http://www.pacificspirit.com/blog/2007/09/13/using_xml_schema_10_when_can_language_components_be_removed_and_maintain_backwards_or_forwards_compatibility"
<DanC_lap> "[Definition: A language is Extensible if the syntax of a language allows information that is not defined in the current version of the language.]"
NM: I don't think it says that, but I'm increasingly convinced that it SHOULD say that.
<DanC_lap> ^ I read that as "A language is Extensible if there are two texts that map to the same semantics". Asking Dave if that's as intended seems to yield "it's complicated"
TBL: I'm torn between saying that, which is correct but confusing to newbies, vs. talking about the places where you can stick new stuff in.
HT: Having redundency isn't enough.
NM: Necessary, but not sufficient?
<DanC_lap> (the C++ case seems like a _not_ extensible language. they assign stuff to texts that used to be _illegal_)
DO: You can have a language that has no redundancy. WS Security causes faulting.
<DanC_lap> (you can have an extensible language with no redundancy? oh... he explains... a more subtle notion of redundancy than I meant)
<DanC_lap> (in our model, there are usually several ways to look at a format as a webarch:language)
<ht> HST mentions the role of "Colorless green ideas sleep furiously"
<Norm> Noah: If your text isn't in the accept set, all bets are offf
<Norm> ...If it's in the accept but not the defined set then we can only tell you something about it (scribe got lost)
<Norm> ...And if it's in both sets, then you can say it's perfectly good information even if my app doesn't like it.
<Norm> ...What worries me is that we seem to bounce between these levels without being careful.
<raman> have been on about 10 minutes it's hard to understand the phone conversation, room is echoing ...
<DanC_lap> (degraw's stuff treats processing formally, I think)
NM: I do note that this doesn't much build on part 1. My nervousness with processing model is, in part, that we need to connect it to our part 1 concepts of information etc.
SW: I thought we were going to talk more about reduction. Is there something in the strategies that shows a forward compatible restriction that's not a reduction.
<daveorchard> adding optional components ( in XML, this is generally elements and/or attributes)
<daveorchard> adding optional content, for example extending an enumeration
DO: From section 1.2:
... adding optional components ( in XML, this is generally elements and/or attributes)
... adding optional content, for example extending an enumeration
SW: Are you talking about one way message scenario?
<DanC_lap> (there's a strong connection between examples and audience. I'm noodling on our audience and whether the GPN advice is likely to convince them, and it does seem like WS-* messaging designers are more natural audience members than, say, HTML 5 designers)
<daveorchard> Language L2 is fully strictly compatible with Language L1 if L1 Accept Text set > (superset) Language L2 Accept Text set > (superset) L2 Defined Text set > (superset) L1 Defined Text Set AND every text in L1 Defined Text set is compatible with L2 AND every text in L2 Accept Text set is compatible with L1.
SW: Remind me on forward and backward compatible.
DO: Language L2 is fully strictly compatible with Language L1 if L1 Accept Text set > (superset) Language L2 Accept Text set > (superset) L2 Defined Text set > (superset) L1 Defined Text Set AND every text in L1 Defined Text set is compatible with L2 AND every text in L2 Accept Text set is compatible with L1.
SW: I didn't quite parse "fully strictly"
DO: You asked for some examples. That's them.
SW: OK, I'll check out
... Fully seemed to be about being very tolerant, strictly seemed redundant.
DO: I may have overloaded
... Where do you want to go now?
SW: I've only gone there because it crept into the IRC log
NM: I'm still confused about the lack of connection to the part 1 terminology
DO: That's intentional. I think
going to the rigorous terminology will throw off the readers we
intend to address.
... I think we really want to say, build extensible languages and a model for them.
<DanC_lap> (huh? you don't want to use the definitions in the advice? that seems backward.)
DC: Not if the terms aren't defined.
NW: I'm worried too.
TBL: Are we saying "to make extensible languages, make them extensible".
DC: Yes, make it comprehensible, but work from the base.
TBL: What's our feeling about examples.
<DanC_lap> (I'm not at all surprised this is hard.)
<Zakim> Norm, you wanted to say that I don't read that definition the same way as Dan
<Zakim> daveorchard, you wanted to say that a language can be extensible but NOT redundant and NOT forwards-compatible evolvable.
<Zakim> Noah, you wanted to talk about processing
NM: I think we sometimes need
more rigor consider the text that says: "Preserve existing
information Rule: Any Language intended for forwards-compatible
versioning MUST require that extensions MUST not invalidate the
non-extension text's information."
... Is there some operation called invalidation that can be done on information.
<DanC_lap> (this 'invalidate' stuff comes back to what I called an open research problem around compatiblity of information.)
<DanC_lap> (again, it doesn't surprise me that we're having trouble giving general advice; the traditional formal models don't help much here.)
DC: Talking about compatibility seems better than "not invalidating"
TBL: In a lot of cases things aren't backwards compatible, there's limited damage. Consider HTML tables. If you put a doc with tables that don't understand them, then you can still get useful stuff out. Graceful degradation.
<timbl> "Applications are expected to behave properly" has som room for judgement it seems to me
<DanC_lap> (tbl's point about costs is another reminder that economics figure in to language design and evolution a whole lot, and our formal models don't touch on that at all. maybe that's ok, I dunno.)
NM: But I think we're missing a chance to work through the info model. In the HTML case, a processor that knows tables will have in its info model will know "There's a table there". A processor that knows the older language only knows "there's a <table> element there."
DO: If what I get is that I1 is a subset of I2, then... there has to be some relationship there.
<DanC_lap> (looking at http://www.marcdegraauw.com/files/axiomsofversioning.html ... he formalizes this information stuff as behavior of processors. hm.)
SW: Where would you go, Noah?
NM: Not 100% sure, but I'd be inclined to try to talk about what we do and don't know about compatible information. I think that in some simple cases, e.g. that map to relatively orthogonal named properties, you can do a generalized solution. In practice, I think knowing that a traffic light being off and a traffic light being green are incompatible is domain specific.
<daveorchard> I think the HMTL adding tables and being able to extract flight times is a great example.
<daveorchard> Which is very different than a PO adding a security token..
<daveorchard> And it seems that the language designer makes their best guess as to how to do compatibility
TBL: I think we worked hard on the terminology and should keep it. Haven't read strategies carefully enough. It's finding it difficult to add values for users. I wonder whether we could illustrate these with particular, or even notorious examples where versioning has or hasn't worked well.
<daveorchard> Then producer of a new version decides whether they want to produce an instance that is compatible or not according to the rules in V1..
TBL: You could say HMTL growth was successful, allowed tables to be put in. Could give the validator as a bad example, because it stopped people from extending the language when it needn't have.
<DanC_lap> (examples: HTML 1 to 2 to 3 to 4; XSLT 1 to 2; XML 1.0 to 1.1 (bzzt). CSS.)
TBL: Is there a story we can tell about CSS not having a version number?
<DanC_lap> (other examples I hear about include: XBL)
TBL: Could tell the story about
IETF admonitition to typically add x-____ headers, and that
didn't work out.
... Talking about them would be good.
<DanC_lap> (the moz-rounded-corners example brings us right back to the class attribute registry discussion)
<Zakim> timbl, you wanted to ask about what classic examples we know
NM: Would you try to connect them to the formalism.
... The real problem with the x- stuff was that there was no transition to the non x- stuff.
... Given examples will bring this alive.
<DanC_lap> +1 more examples sooner
DC: Maybe we could do more for the specific examples to flesh them out.
TVR: I've been confused about the
business of when you put HTML and CSS together.
... When I have an HTML document and CSS, different processors may give you a given look.
<daveorchard> The XML document has many more examples and details at http://www.w3.org/2001/tag/doc/versioning-xml#iddiv190659352
<DanC_lap> (I think populating the CSS column is likely to be interesting and non-trivial; whether CSS's versioning story is exemplary is a source of unending discussion in circles I run in.)
TVR: Start with a document D and stylesheet S. S has a property that hides what it's applied to, but only one processor honors it. What does that mean.
TBL: Canonical example. People who generate Web pages will tell people which version of CSS is being used where.
<Stuart> If you regard HTML or HTML+CSS as a presentation language, then surely information/meaning is appearance on the screen!
NM: I think you can do at least two information mappings for that case. In one, you just note that the property is there, and leave it to the processing level to know that skipping a hide instruction is incompatible. In the other mapping, each text is labeled at the information level as displayable or not. In that case, you'll see that the information as mapped is incompatible.
TVR: I think you need some warning (TVR--can you help me scribe this better).
SW: Dan, what would you do next?
DC: I still think dealing with forwards compatibility is one of the more interesting things we can do. The connections from that section to the definitions could be better. The idea of doing more examples could add value.
DO: We kind of focussed on that first section. There's stuff in 126.96.36.199 "must accept unknown extenstions", where there are more examples.
<DanC_lap> (hmm... I didn't say "could be better"; I suppose it's sort of a fair paraphrase, but I don't at all mean to say "coudl easily better")
DO: The 188.8.131.52 is accept the
unknowns; 184.108.40.206 is to provide a fallback.
... Also some stuff about understanding version identifiers.
<DanC_lap> (perhaps I'm not a typical reader, but I'd probably prefer headings like "versioning in HTTP 1.1" to "ust Accept Unknown Extensions")
<DanC_lap> (hmm... "text portion"... I think the pattern to note there is the flat-list pattern)
DO: For example, talking about "processors must not fault if receiving the expected major version numbers"
SW: I skimmed it recently. I see myriad good practice notes which describe themselves as rules, and not knowing in what context they apply. I infer they don't all apply simultaneously. Find myself asking: which rules do I use when. I'm lost in a sea of rules.
<Zakim> Norm, you wanted to encourage the editor to reconsider his position about using the terminology in the strategies document; making the whole suite of documents tighter and crisper
<timbl> For example.
<timbl> Provide Extension handling Rule: Languages SHOULD specify how unknown extensions are handled. --->
NW: I'd like to encourage you to reconsider your inclination to keep the terminology out of the strategies, but I think the documents would be better if they were tighter and more rigorous. We could also in principle add a primer etc., but I think we'd be better off. This is the first time I've heard you say you weren't trying to do that, and it somewhat disappoints me.
<timbl> An extensible languages provides mapping from documents in any extended set to dopcuments whose semantcis is lready defined.
SW: 10 mins to 5PM. Need to wrap up. This is all the time we have scheduled. Need to decide where to go.
<timbl> The the next one is unnecessary in facrt "Preserve existing information Rule: Any Language intended for forwards-compatible versioning MUST require that extensions MUST not invalidate the non-extension text's information.".
<timbl> Sorry, /me waqs not wrapping up
<timbl> 'Forwards-compatible requires extensibility rule: Any Language intended for forwards-compatible versioning SHOULD have extensibility."
TBL: Consider Forwards-compatible
requires extensibility rule: Any Language intended for
forwards-compatible versioning SHOULD have extensibility." Is
this saying: "For something to be extensible it must by
extensible". If it were crisper, you could tell.
... If we related it to the terminology thing it would be less readable, but more solid.
SW: I think I've heard that the issue is "What really are the messages that the TAG wants to deliver".
TBL: I think we want to give people patterns they can remember and apply.
SW: Do we have a catalog
TBL: To some degree they're in the good practice rules.
<DanC_lap> (yes, the GPNs make more sense as patterns, since people know that patterns sometimes apply and sometimes don't.)
NM: I think we can also help people to think a bit more clearly. E.g. do people really know how different languages use version ids.
<daveorchard> Enjoy your sail!