Discussing section 1.1.1 of the draft finding: http://www.w3.org/2001/tag/doc/versioning-20060929.html#iddiv377194600
TBL: It's always the case that for each language, the accept set is at least as large as the defined set.
DO: (quoting from the draft) Language L2 is strictly backwards compatible with Language L1 if L2 Defined Text set > (superset) L1 Defined Text Set AND every text in L1 Defined Text set is compatible with L2.
TBL: Compatible? You can't say a text is compatible with a language.
DO: Are you all happy with the use of accept vs. defined here?
NW: Haven't we been wrestling with this for 2 days?
HT: I remain unsure that hanging conclusions on accept vs. defined is right thing to do.
<Noah> (Noah thinks he agrees with Henry)
<Norm> I thought we had and intended to suggest that DO proceed with something new
<Norm> Somehow it seems to have had the opposite implication
HT: Because it depends on something like XML Schema for definition...
HT: I pressed you yesterday, Dave, and that's what I thought you said. Wildcards vs. elements.
<DanC_lap> DanC: please continue my action to review the definition of backward/forward compatible
DO: Accept is fairly clear. Defined might be more problematic. I think gap between is important.
Net of a discussion not minuted in detail:
Defined text set is a set of texts, each of which has the characteristics that all of its content in some sense contributes directly to the information conveyed (I.e. does not have "extra stuff" that might be tolerated but not acted upon.)
HT: Think I agree with Noah. Suggest for Language L2 is backwards compatible with L1 if and maybe only if every text in L1's text set L1 is compatible with L2 with respect to that text.
DC: Let's zoom out.
<Zakim> DanC_lap, you wanted to ask to zoom out to the outline/TOC
DC: Look at the table of contents. I'm hoping
... What's the table of contents, timelines, etc. Let's go around and ask what people are after. I'll start.
... There are some versioning strategies in section 8. A lot of our readers will go to section 8. Maybe we should move that earlier and put all this stuff in formal appendix.
... I wouldn't mind instead of first middle last name talking about evolution of languages like XSL v1 to v2, SVG, etc.
... Regarding timing. How about 2 phases?
... Maybe we have something that's acceptable but not beautiful in 2 months. More later.
... The stuff I'd really like to do doesn't fit in available time. Not sure what to do about that.
DO: Sounds like you're after a look at the
... I think that would be useful. XSLT is this; Docbooks used that; etc.
DC: Yeah, get them to agree that they did it (scribe thinks Dan probably meant: get them to agree that we told their story right)
DO: Strategies 8.3 and 8.4 are actually quite difficult to do using XML schema 1.0. Schema 1.1 will help. I would like to reference.
NM: Watch for schema 1.1 not coming out in the form that appears in the working drafts. If we reference it and then it changes, we'll have to update our finding accordingly.
NW: I'm not sure I'm prepared for the question as to what to do next on versioning..
TBL: Hopes and dreams for this finding?
... Like to see it layered. The stuff we're just discussed should define backward compatibility.
... We've touched on monotonic languages but haven't defined them.
DC: In text or document (scribe isn't sure what this meant...it could have been an inaccurate transcription of what Dan said...suspect Dan actually asked: "Do you mean we haven't defined monotonic languges in Dave's draft or haven't defined them in our discussions here?")
<DanC_lap> (I'm willing to take an action to suggest text to define "monotonic language" in terms of information/claim/compatbile/etc. )
Some discussion which seemed to agree we made progress in the room on monotonic languages, but DO reminds he has no action to write it up.
TBL: You can say more for monotonic languages.
You can connect the wildcards to the information extensibility.
... We should do studies of things like XML 1.0 to XML 1.1, which doesn't fit monotonic. It caused trouble.
... In RDF what's interesting is the monotonicity in the relation from data model to semantics.
NM: Isn't the syntax to DM also monotonic.
TBL: Maybe. Probably depends which syntax.
DC: Definition of monotonic does not appeal to chars?
HT: There are two levels. One for each mapping.
TBL: Then we can get to tell a story about how we get good extensibility for RDF?
DO: Different finding document? We don't do XML schema here.
TBL. Yes, you're right. Probably different document.
HT: There are things that are easy to say about monotonic languages...
DC: Are we off track?
TBL: I'd love it if we got terminology sorted out. Surprised it's taking so long.
DO: We've been on 1.1.1 for a year.
... People are looking hard at section 8.
NM: That looks like XML-related stuff.
NM: Why is that in part 1?
DC: You're asking that question out of turn, therefore not in order for discussion now.
TBL: I think you have to do terminology first.
... You've got to have the terminology in order to use it.
... Chapter 8 should depend on the terminology. Will also depend on the type of XML document. Is it monotonic? Story is different for different ones.
... Somewhat inclined to put both XML and RDF in chapters 8 and 9 respectively.
DO: Chapter 2 is a set of questions.
... Some strategies inherit from other specs. E.g. Web Services Addressing inherits mustUnderstand capability from the SOAP container.
TBL: Not sure if you want a separate doc for
... SOAP assumptions are in a different world from XML.
DO: But the WS communities do have XML
questions like 8.2 vs. 8.3.
... Not sure I need see them all.
NM: Clarification. Tim, don't we have a part 2 for XML? Are you proposing to merge part 2.
DO: Part 2 is about XML Schema, not XML per se.
TVR: No comment.
NM: On the one hand, I'm sympathetic to the
fact that users want concrete advice. On the other hand, we're well along on
a powerful and very general story that I think is valuable. Meanwhile, I see
limited TAG resources. I think we need to do a smaller job well, but am not
100% sure which parts to cut and which to keep.
NM: I'd like to see something about recursion [composability?], where each <name> part is its own sub-language. The same story we tell for versioning of the texts which are the document as a whole, we can tell for the sublanguages like <firstName>, <telephoneNumber> or whatever. That's really nice, clean and powerful.
NM: I'd prefer to see most of the XML stuff separate, though which stuff we publish where is mostly an editorial decision. In the end, I think we should say that the way to look at XML is as a run of text, since as I have said, it's not just the markup that matters; the content such as zip codes and stuff gets versioned too. By telling a story that starts at the text level rather than the markup per se, we deal with everything including the markup in a uniform way. I find that very appealing.
TVR: I'll comment after all. This is sufficiently complex that I think we should indeed put it in small chunks.
TBL: Do you really think we're better in separate documents?
TVR: I think readers of the first small doc(s) will give us useful feedback.
DC: Do you have a picture of that?
TVR: I'd start with a "capsule" that has a
concrete example, and hints at a generaliztion; and then 2nd chapter tells
story like the one from this morning. For document 1, stop there.
... World will then tell us whether to do more.
DO: Three years ago, this started with a simple
example of adding a middle name into an XML Schema.
... Section 5 used to be earlier.
... People added new questions and options. The simple story got prefixed with all this other stuff.
... Now because we used the word compatible, we got pushed on the word compatible.
TVR: I still think we need to publish early. Then again, everything we write is public. Still, not everything we put out there gets read as it's written. Audience will be wider if you declare a piece of it "done". We can't afford to keep these things going for 3 years.
DO: To a certain extent, XML Schema is spending some time thinking about compatibility.
<Zakim> DanC_lap, you wanted to ask about which specific thing to start with
DO: People like Marc de Graauw have been actively discussing details of things in section 8. That's a good sign.
HT: I think we need to ground the notion of compatibility somewhat like what we did this morning, but remain unconvinced that the defined/accept set distinction is necessary.
HT: For a large class of XML-based languages, it's quite straightforward to define what we mean by monotonic, and to tell whether your language is monotonic. If it is, then the first 3 or 4 sections, or maybe even the first release of this document is for you. We can do a pretty complete story. That may be all we're going to say, either for now, in this version, or forever.
HT: Then we can say in a section 2 how things get more complicated if your language is not monotonic. I want to be sure we don't appear to say we're covering more than we really are. Don't want to imply we're covering everything when we're assuming monotonicity. Don't mind if we do 80/20, as long as we're clear on what we have and have not covered.
HT: Still not sure whether to do everything, but in 2 parts, vs. only talking about the easy case, and warning about the hard cases not covered.
DO: I'd be happy with a finding that said "How to version 80% of the Languages Out There" as a bumper sticker.
<timbl> I do not think that the majority of languages in fact are monotonic, RDF being a significant exception.
<Zakim> DanC_lap, you wanted to ask about which specific thing to start with
NW: I want to support what Dave is saying about not tripping over last fraction of obscure stuff.
DC: TV you did say we should pick something specific. We did start with Firstname Lastname, but I'm not interested in that as a finding. I'd like HTML2 to HTML4. Strong preferences for W3C languages.
DO: Not as interesting. A lot of the languages people are working on are using XML, using languages like XML Schema or Relax.
TVR: Another example would be microformats. Looks like there will eventually be problems there.
<timbl> uSchema is the new schema langauge for defining valid uFormat combinaions.
<timbl> - First,middle,last name
<timbl> - HTML 2 to 4
<timbl> - Soap messages with headers
<timbl> - uFormats
<timbl> - HTTP headers
<timbl> - HTML4 o XHTML <--- ***
NM: I kind of agree with Dave. The measure of our examples should be how many designers of future languages will say: "yes, that example teaches me what I need to know for designing my languages." I'm not quite convinced that HTML 2 to HTML 4, interesting as it is, isn't more of a one-off in its versioning issues. The first/middle/last, whatever its other pros and cons, is a good poster child for lots and lots of data-oriented languages that transmit basically property/value pairs, etc.
<timbl> - XML 1.0 to XML 1.1
TBL: We haven't talked, except at lunch, about things like mustUnderstand, economics of adoption, etc.
<timbl> - RDF from n ontologies to M > n ontologies
VQ: Would like to conclude this discussion for now.
<timbl> I have typed in some examples which we have mentioned
<timbl> - XSLT
<Noah_> I'm made a bit nervous by Tim's comment in IRC above that monotonic languages are the exception, not the rule. If he's right, then we need to focus in other areas I think.)
Reviewing Actions Relating to the Versioning Finding
PENDING ACTION: DO, accepted on 22 Sep 2005: with NM continue and extrapolate the versioning work DO et al have been doing already, updating the terminology section. Reconfirmed 5 Dec 2005, 14 Feb 2006, 12 Jun 2006.
This action is: DONE
PENDING ACTION: HT, accepted on 22 Sep 2005: make sure that what he is doing with ontology of XML infoset fits with what DanC is doing on ontology of Language etc. Reconfirmed on 12 Jun 2006.
HT: I think it's done, overtaken, whatever.
DC: Really? Too bad.
HT: I'll keep at it, don't need an action.
DC: Prefer an action.
HT: OK, what action? I propose to at least try and flesh out story on monotonic. Maybe put in as conference paper. Not sure.
<timbl> [why, if they are an important and subset of languages where we can make more asumptions and make more conclusions]
HT: I don't see picking up XML Infoset ontology. Think I got what I wanted, but didn't finish it. It was an RDF learning excercise for me.
Henry's action is: DROPPED.
PENDING ACTION: VQ, accepted on 3 Mar 2006: Write to www-tag about CSS versioning being a problem "levels". Reconfirmed 12 Jun 2006.
This action is: PENDING
PENDING ACTION: DC, accepted on 3 Mar 2006: Look at the document and see if it is good for informing on this SMIL problem of multiple namespaces. Reconfirmed 12 Jun 2006.
DC: Tried a couple of days ago to do this and failed. Can't find what SMIL problem is. Searched a bunch of stuff.
VQ: Has to do with having a different namespace for each version of language, I think.
DC: I vaguely recall it.
<timbl> Henry, the declaratin in HTML* to ignore tags you don't understand makes the languages monotonic.
DC: I propose to withdraw this one.
This action is: DROPPED
PENDING ACTION: DC, accepted on 8 Aug 2006: Review definitions of partial understanding, backward compatible, and forward compatible. Progress report.
This action is: CONTINUED
<timbl> So HTML and RDF are two examples. And HTTP headers. So we have 2 big monotontic languages.
VQ: Any new actions relating to versioning? Dan and Henry said something about monotonic languages.
<ht_vancouver> Tim, yes, I think that's right for HTML -- what I have in mind is to define monotonic in the terms of the discussion paper.
TBL: I thought I heard Henry said he was going to do this anyway?
HT: At least datamodel to semantics.
TBL: Yes, follows from ignoring TAGs.
DC: There are all kinds of tags like <form> you can't ignore.
General agreement: Henry will figure it out.
ACTION: Henry to extend his paper to a definition of monotonicity and its relevance to our versioning finding.
<DanC_lap> (if there are few monotonic languages, the concept may still be relevant if the non-monotonicity in lots of languages comes at high cost.)
VQ: What about the diagram?
<DanC_lap> ACTION: DanC to capture UML diagram for the minutes
VQ: Any other actions on versioning before moving on?
DO: Not sure where to go. Obvious thing is to
take feedback to update 1.1.1.
... Still a schism on defined/accept sets vs accept set and information.
... I tried several types of phased compatibility.
... Didn't get the traction I hoped.
DC: I'm content if you wait on other actions.
NM: Well, if I were Dave, I'd think about the size of the table of contents. I think it implies more than we can do to the level of quality the TAG needs to do. I'm not recommending which fraction should survive, but I think this will go better if we consider a significant reduction in scope. This is taking a long time because there's too much to do well.
HT: Was conflicted about how to proceed. Had a
very useful discussion with Ian Jacobs.
... I have some ideas I'm hoping to work into first few sections. Some matrices with desirable characteristics vs. particular technologies.
... Want to cover which are basically technical and which social.
... New draft will be forthcoming, but not quite sure when. Will try and clarify likely schedule soon.
... I spoke to Sean Martin of IBM, who seemed interested in the ARK approach to LSIDs.
... I wanted to know what we on the TAG could do that could be helpful vs. hurtful.
... It wasn't immediately clear what we could do that would be constructive.
... There have been some delays in implementing some of the mechanisms in their own spec.
DC: It's not 100% clear they're committed to using URIs.
NM: Do we want to get involved? I would have thought URIs with an lsid scheme were still somewhat better than not using URIs at all.
HT: I will produce a new finding, whether or not you mint a (new) action.
PENDING ACTION: HT, DO, accepted on 18 Apr 2006: Henry and David to update draft finding URNs, Namespaces and Registries. Confirmed 26 Sep 2006.
This action is: CONTINUED. Hope to have a plan in a few weeks.
PENDING ACTION: DC, accepted on 26 Sep 2006: DanC to find timbl's draft, give it to Ivan Herman in preparation for HCLSIG meeting in Amsterdam.
This action is: DONE
Note that Norm is at the moment out of the room.
<DanC_lap> (later rescinded...do not record as an action to be tracked)
ACTION TimBL: with Norm, draft semantic web architecture stories and such.
<scribe> Pending actions:
PENDING ACTION: HT, accepted on 6 Sep 2005: track progress of #int bug 1974 in the XML Schema namespace document in the XML Schema WG.
This action is: CONTINUED. Hoping for progress by end of October.
<DanC_lap> VQ finds the action on TBL/NDW in the issues list.
(cancelling the action inadvertently opened a few lines above)
<ht_vancouver> Ed, are you there?
VQ: This was put into the agenda in part because some of us will be leaving in 3-4 months.
<ht_vancouver> EdR, are you there?
<ht_vancouver> You might want to dial in?
<ht_vancouver> We're moving on to discussing future plans
VQ: Four TAG members' terms end 31 January
2007. They are David Orchard, Ed Rice, Vincent Quint and Norm Walsh.
... All except Vincent Quint were elected. Vincent was appointed.
NM: I think it's a good thing to give the AC an early heads up that the election is potentially a big one in terms of number of seats that could in principle turn over. The earlier they start thinking, the better the candidates we'll get I think.
TBL: We could maybe be ready for an Arch Document Volume 2. It would be a bit scattered, but that's not necessarily a bad thing.
NW: Or we could republish Vol 1.
NM: Some, not all, of our newer findings seem to fit better as updates to Vol. 1. For example, Vol. 1 already tells a story about metadata in URIs.
TVR: Should we write down what we see our future to be?
DC: The communications team does some of that.
TVR: But it doesn't have a technical architecture.
TBL: Some aspects are covered, like integrating the mobile space with the rest of the web.
HT: E.g. there's nothing about peer-to-peer. That's an architectural future.
<DanC_lap> (about where W3C is heading... W3C comm team has some about that in http://www.w3.org/Consortium/future )
NM: We always have the tension between doing forward looking architeture, vs. documenting the architecture of those aspects of the deployed system that suggest good practice. I believe in good forward looking architecture, but it's hard and risky. We've often done better looking back.
DC: I was looking at the XHTML charter, and remembered that Tim used to do roadmap diagrams.
DC: We could do a roadmap, presumably starting with what Tim has already set out.
HT: There are risks. Not clear the last time we did it there was a lot of impact on W3C agenda.
DC: I think that's because we didn't finish.
HT: I think the TAG should raise an issue on well formed vs. TAG soup for HTML.
TVR: The risk is that we back into a decision without appropriate conscious decision.
HT: Note that the draft charter does take some positions on this.
<EdR> Tim's book has a whole section 'mind to mind' (I think) which discusses a mid-term vision of where the web should be.
TVR: We need to rethink bifurcation introduced by application/xhtml+xml mime type
HT: We have messages from Ian Hixie that push back on authoritative metadata. They're well reasoned. Maybe we should respond, either agreeing or not.
DC: I think we've already responded before that we disagree.
TBL: No, I think we took our position before his note. That's not really a response.
HT: I'd like to go through an orderly TAG analysis. I'd like to look carefully at the points he makes.
TVR: There's a meta issue this raises. A lot of
our processes date from a time when the primary communication was email and
the primary output was working draft.
... Now blogs have emerged. Someone writes something in a blog that essentially "debunks" something that a W3C group, possibly the TAG, has produced. We don't have an effective mechanism to responde.
... Sometimes we think about those things, and we appear unresponsive.
<EdR> +1 agree with TV on Blog
TVR: I think every W3C working group should have a blog. I think mailing lists as the only channel of communication is no longer sufficient.
DC: Was it ever?
TVR: Not sure. The communities think the conversation is not happening.
DC: Interesting, but a process discussion. Is it out of scope for us?
VQ: I agree. It's close to a process issue.
NM: I think we should get to think about how we make the TAG's own communications more effective, nimble when necessary, and visible.
<Norm> I think this runs both ways. I might comment on the W3C in an essay on my blog but I wouldn't expect any sort of official reply. I think it's incumbent on me to comment with email or whatever the W3C says is the official channel if I want a response.
TVR: We should revive W3C Notes in the form of blogs.
DC: Blogs are typically personal. Can't have a WG blog.
NM: I'm not convinced all blogs are personal.
TBL: The blogsphere works in different ways from W3C. Less accountability etc. Wonderful escape valve. It is sometimes important in rescuing us from things that are indeed missed. Overall, the signal to noise ration is an issue.
<Zakim> dorchard, you wanted to talk about future topics including verisoning
DO: Versioning is important to my company and
... Seems to me we're missing the mark a bit on hot web topics.
... User-facing front-end stuff is getting more interesting.
<DanC_lap> (indeed.. AJAX, bittorrent, p2p... I'd like to budget maybe a little more TAG time to noodle on those.)
DO: I think focussing on that stuff would be useful.
TVR: I think a lot of the Web 2.0 stuff isn't new. Some of the same things are moving server to client. The TAG should work on stronger infrastructure and framework for this stuff.
DO: Marc Hadley, Mark Nottingham, Joe Gregorio
and I have been working on a URI templating language. Relates to WADL.
... Feels to me like there's some stuff there.
TVR: Doesn't feel like a TAG thing.
DO: You're missing my point.
<Zakim> DanC_lap, you wanted to noodle on tag-soup, well-formed, mime type, and the AC meeting
<dorchard> The link is http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-00.txt
<dorchard> also dewitt clinton and james snell
<DanC_lap> HT is excused
<DanC_lap> NDW is excused
<DanC_lap> (TBL projects a drawing of the "we shoulds" from this discussion; DC hopes it ends up in the minutes
DO: As I've said, the TAG needs to be on top of these high momentum developments.
TVR: We have to not just be on top of it, we have to be perceived. What makes it tick is well designed URIs.
NM: Well, we do have a finding about metadataInURIs. I'd be glad to delay it if we need to say more about Web 2.0.
TVR: When we think about doing a Web 2.0 API at Google, the key design point is the structure of the URIs.
DC: Metadata is not the word we want to use.
NM: I'm not hung up on the packaging of our findings. I'm making the point that we've been working in very close to the pertinent space, and the draft finding has improved.
<dorchard> Also, http://www.w3.org/2001/tag/issues.html?type=1#URIGoodPractice-40
TVR: I'd wrap up the current finding, and do another on URI engineering.
DO: See URIGoodPractice-40 (http://www.w3.org/2001/tag/issues.html?type=1#URIGoodPractice-40)
TBL: Mapping software puts lots of state after the # until you mint a link.
NM: Not Google maps.
TVR: Well, importantly, there's an opportunity to explain some things about things after the # that will help the community a lot.
VQ: We are adjourned.
... Everyone available for next Tues telcon?
DO: Canadian Thanksgiving next week.
DC: What would we discuss?
TVR: What about TAG futures?
VQ: I will put together an agenda Monday