W3C

- DRAFT -

TAG in Southampton, day 1

17 Sep 2007

Agenda

See also: IRC log

Attendees

Present
Stuart_Williams, Noah_Mendelsohn, Tim_Berners-Lee, Norm_Walsh, Henry_S._Thompson, Dan_Connolly, Rhys_Lewis, David_Orchard*, TV_Raman*
Regrets
David_Orchard*, TV_Raman*
Chair
Stuart Williams
Scribe
Henry S. Thompson, Noah Mendelsohn

Contents


 

 

Convene, take roll, review records and agenda

<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

http://www.w3.org/2001/tag/2007/09/13-tagmem-minutes

RESOLUTION: to approve minutes 13 Sep

f2f planning

<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

<DanC_lap> http://en.wikipedia.org/wiki/San_Servolo

<DanC_lap> http://en.wikipedia.org/wiki/TED_%28conference%29

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]

HttpRedirections-57, HTTPRange-14 follow-up, review of "Cool URIs for the Semantic Web"

<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 ways
... 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 infrastructure
... 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

<DanC_lap> http://www.w3.org/TR/grddl/#base_misc

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 )

<Stuart> https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html

<DanC_lap> ( I also find https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html ... date pending... )

<DanC_lap> https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html

<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. . .

[Coffee Break]

[resumed]

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

https: //gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html

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. is about
... 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

NM: 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"?

TBL: no

<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?

SW: How?

<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

TagSoupIntegration-54: Distributed Extensibility

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 microformat deployment.
... 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.

DC: Complicated.

<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.
... 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 deployments.
... 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.

DO: ???

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 weakness.
... 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

<DanC_lap> http://www.tbray.org/ongoing/When/200x/2007/09/14/Lousy-Aggregators

<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> eikeon

<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.

Face to Face Scheduling Revisited

NM: Dave, we had talked about asking you to host a face to face in or near Vancouver Tues-Thurs Feb 26-28. OK?

DO: Yes

****BREAK****

<ht> Uncaught exception: Permission denied to call method XMLHttpRequest.open

<ht> zakim +0 is ht

XMLVersioning-41

ACTION-15

<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).

DC: How?

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:

<dorchard> http://lists.w3.org/Archives/Public/www-tag/2007Jul/0004.html

<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.

DO: No.

<Rhys> > Stuart's review

DC: You said:

Suggest replace:

"Defn: A *Language* ..."

with:

"Defn: A *Language* consists of a set of admissable text;

DC: Why did you want that change.
... 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 tautology.
... 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.

http://www.pacificspirit.com/blog/2007/09/13/when_can_language_components_be_removed_and_maintain_backwards_or_forwards_compatibility

http://www.pacificspirit.com/blog/2007/09/13/using_xml_schema_10_when_can_language_components_be_removed_and_maintain_backwards_or_forwards_compatibility

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 need redundancy?
... 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 definitions.
... 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?

HT: Yes.

<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

<timbl> ( http://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_furiously)

<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 examples.
... Fully seemed to be about being very tolerant, strictly seemed redundant.

DO: I may have overloaded fully.
... 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.

TBL: Yes.
... The real problem with the x- stuff was that there was no transition to the non x- stuff.
... Given examples will bring this alive.

<daveorchard> http://www.w3.org/2001/tag/doc/versioning-strategies#iddiv194353056

<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.

DO: Right.

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 2.2.2.1 "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 2.2.2.1 is accept the unknowns; 2.2.2.2 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.

<Norm> ack

<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.

Adjourned.

<daveorchard> Enjoy your sail!

Summary of Action Items

[NEW] 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]
[NEW] ACTION: Norman review Cool URIs for the Semantic Web [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action03]
[NEW] 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]
[NEW] 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]
 
[PENDING] ACTION: Noah Mendelsohn to draft a blog item for review and, pending creation of a TAG blog mechanism, post it (ACTION-28) [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action06]
 
[DONE] ACTION: 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]
[DONE] ACTION: on Stuart Williams to complete review of terminology section of of 4 July versioning draft. ACTION-35 [recorded in http://www.w3.org/2001/tag/2007/09/17-tagmem-minutes.html#action08]
 
[DROPPED] ACTION: 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2007/09/21 22:19:38 $