See also: IRC log
DC: Regrets: Stuart
<timbl_> Regrets for 30 April - I will be in Nashville
DC: Next Telcon: Propose: 30rd April -- scribe: Rhys?
<ht> Hmmm
HT: Rhys has sent regrets for today.
RESOLUTION: we will meet next 30 Apr, Rhys to scribe, Stuart to chair.
<DanC> minutes 16 apr
RESOLUTION: minutes for 16 April 2007 are approved ( http://www.w3.org/2001/tag/2007/04/16-minutes.html )
RESOLUTION: the agenda for today's meeting as proposed in http://www.w3.org/2001/tag/2007/04/23-agenda.html is approved
<Zakim> Norm, you wanted to add an agendum
<timbl_> ________________________________________
<DanC> "Marc de Graauw wrote an interesting article in XML.com on how to use version numbers in XML." -- http://www.pacificspirit.com/blog/2007/04/19/what_do_version_identifiers_identify
DO: I looked into HTML versionining Marc deGraauw wrote an article on xml.com, spurred in part by our earlier discussions. He proposes you give not a single version, but indicate each version that you believe the document conforms to. I had noted earlier the question of "what does a version number identify?" His response gives one answer. I used an example with a middle name, in which the document conforms to both a version 1 and a version 2. What to do then? Label with v1 as the "oldest" it's compatible with? Version 2?
<DanC> "The fundamental problem with a version # in a document is that it doesn't provide for a given document to be valid under more than one version."
DO: So, one of the problems with a single version number in a document is that it doesn't give a way to express compatibility with more than one version.
<Zakim> Norm, you wanted to say that if you put a version number in an instance document, that's an assertion that it conforms to that version
DO: In XML, I've suggested using a single namespace name as the scope for a (set of?) compatible versions.
<DanC> Norm: if you put a version number in an instance document, that's an assertion that it conforms to that version
DO: My answer is, that all works out great, and is often what is used. The problem is that if you say "that's docbook v 4.2", what does a receiver that knows about version 4.1 do? How do they know whether your forward version is ok to process? In my next article, I wrote about needing to know about the mappings from one version to another. For example, the rules for how we'll lable new version instances to indicate whether you can or cannot safely process wrt/ older rules.
NW: If you have that elaborate mechanism, that's fine, but it's also fine to say "if you don't know the version, process at your own peril". I wouldn't expect that to hold true across the board.
<dorchard> NM: hitting a lot of the right points. Discussion makes me nervous because the discussions focused on mechanisms very early.
<dorchard> NM: We're getting back to the fact that for different languages and in different communities, the calculus of evolution/versioning is different.
<dorchard> NM; We should expect that different communities are starting to play around with definitions of the language
<dorchard> NM: what WG grabbed version 5, as opposed to version A.
<dorchard> NM: could easily be very different
<dorchard> lost scribing ability.
<DanC> noted, dorchard . I'll deal.
<timbl_> The versioning system is very much something which depends on pre-agreed conventions across the language family. All kinds of thing are possible, but they must be agreed. Eg for DocBook they could and for HTML they have been defined. XML schema could be* and OWL is used to write the conventins down machine-processably.
<dorchard> NM: for each it will be different
<Zakim> DanC, you wanted to concur that much of the value of version identifiers is an implicit claim about other versions
<dorchard> NM: could be single version #, multiple versions, etc.
<dorchard> DC: there are often implicit claims
NM: My point above was that we're putting the cart ahead of the horse to start with a particular mechanism like a version attribute and ask what it's good for. We learn more by first teasing out assumptions as to how the language changes, who changes it, with what assumptions about interop across versions, etc. In some cases an "in the instance" version attribute will be helpful, and in some cases not.
DC: I concur that much of the value of a version ID is what's implicit in knowing the relationship to other versions.
<Zakim> noah, you wanted to say we're working our way back from a specific mechanism, to unearthing our assumptions about the languages
<Zakim> timbl_, you wanted to say, Once you have a namespace, then you can dereference it and pick up information about how the version relates to other namespaces, whatever their version
TBL: I agree, that a lot of what's important about version numbers is what you've agreed about them in advance.
... In HTML, we've agreed about ignoring tags (and something about version numbers that the scribe missed)
<timbl_> Once you have a namespace, then you can dereference it and pick up information about how the version relates to other namespaces, whatever their version relationships. With ontologies, this can actually define term by term the compatability, so that complete compatible functionality can be boostrapped by client which just looks up the namespace and understands the language (such as OWL or a rules langauge).
TBL: If you've got a namespace, then in essence the version number is a URI, which puts you in a different and interesting world.
... You can use the URI to look things up.
<dorchard> TBL: Can express relationships between languages, such as schema, then can do mapping
TBL: You can't necessarily express that the semantics of the two languages are the same, but you can at least go as far as using things like XML Schema to compare the syntax.
<dorchard> TBL: Using OWL, you can exactly explain the relationship between versions.
TBL: OWL gives you a lot of power to express the relationship between two languages. You an find out exactly which pieces of two languages are the same and which not. That's one of the reasons I'd like to get onto semweb in the TAG, as it gives us the tools for a more interesting discussion of versioning.
<Zakim> ht, you wanted to say you have to make rel'ns explicit
<dorchard> TBL: Why I want to talk more about Semantic Web so we can talk about these powerful mechanisms
HT: What Tim said, but with a different spin:
... The only thing you can say reliably given a version in an instance is that, if it's one you know about or expect, you know what to do.
... Unless you have an explicit agreement about the version asserted and some other, you can't draw any conclusions across verions.
... I agree with Tim that machine-readable descriptions of the relationship are desirable.
DO: I think people have an implicit belief about what version markers identify. If that were made more explicit, users would have clearer idea of what was being conveyed. Consider XML. In the XML declaration, it says that if you see version="1.0" you'll be able to parse it. Maybe you would have better forwards compatibility if it had said you could ignore what you didn't understand. There's a general language issue here. We've talked about defined and accept sets for languages. That's about content. Hasn't addressed the issue of how software will deal with it.
<Zakim> DanC, you wanted to report progress on "DanC to ask Mimasa and Mark Birbeck about feasability of using substitution groups in XHTML modularization, cc public-xml-versioning" and to
<dorchard> And if XML had said "if you see version=1.*" you will be able to parse the document
<ht> I think what I said is consistent with what DO just said
DC: Regarding the fact that there's a versioning architecture for HTML that doesn't apply more generally. True I suppose, but our audience is looking for advice on general good practice. Perhaps giving a name to the "major version changes imply incompatible" idiom would be helpful.
<DanC> http://lists.w3.org/Archives/Public/public-xml-versioning/2007Feb/0000.html
DC: Regarding people not using XML Schema, substitution groups were mentioned awhile ago. I took that to the XML Versioning mailing list.
HT: I followed that thread. Was disappointed. Seemed like Dan asked "could you tell me about X". The answer (from Chris Lilley?) was "well, we used Y".
<DanC> http://lists.w3.org/Archives/Public/public-schemata-users/
DC: There's a list http://lists.w3.org/Archives/Public/public-schemata-users/
NM: I hadn't known about that. As far as I know, http://lists.w3.org/Archives/Public/xmlschema-dev/ is where users are discussing W3C XML Schemas.
HT: Robin Berjon wrote a note about why schema doesn't work for versioning, and I answered. I need to unearth the thread.
<scribe> ACTION: Henry to unearth thread in which he and Robin Berjon discussed XML versioning [recorded in http://www.w3.org/2007/04/23-tagmem-irc]
DC: Trying to decide what priority to give this. I don't think CDF is using substitution groups, perhaps not W3C XML Schema.
DO: I think it's high priority. How to use the mechanisms comes up repeatedly. That's what part 2 of the draft finding is about.
DC: How to do versioning with XML Schema?
DO: Yes.
DC: Did you look at CDF?
DO: Looked at, but didn't do much with. Perhaps should go back to it. I did note that substitution groups cause some issues for decentralized versioning.
DC: CDF says they're finished with Last Call. We didn't comment.
NM: Subst groups are just one of the interesting W3C XML Schema mechanisms that are being applied to solve versioning problems. I think we got focussed on that because of a particular lunchtime discussion at a TAG F2F, but it's not necessarily more important than the others.
DC: did anybody review CDF?
NM: I looked at CDF about a year ago, but not with XML Schema considerations in mind.
<Zakim> dorchard, you wanted to mention that people do version mapping with Schema *a lot*.
<dorchard> NM: reviewed for TAG last year, but not specifically about subst groups
<dorchard> NM: reviewed for TAG last year, but not specifically about subst groups
NM: My point is that substitution groups are just one of the XML Schema mechanisms that can be used for some styles of versioning. The schema WG has studied many others.
DO: There's a lot work going on in my company and others to produce tools that start with an instance authored to one version of a language and help you map to use for other purposes. Lots of drag n drop, auto complete, etc.
<Zakim> timbl_, you wanted to suggest substitution groups may have special properties which make them architecturally unique, and so we should push them rather than other methods. being
DO: Customers are using these tools.
TBL: Pushing back on Noah's suggestion that "there are lots of people out there doing these things and we should be even handed." I feel we invented some useful things in the TAG and substition groups turned out to be the XML Schema mechanism you needed to describe the particular idiom the TAG was advocating. That's Web-like extensibility. We should push for it.
NM: That makes sense. As long as the motivation is "The TAG thinks this is a good way to use XML on the Web, and by the way, subtitution groups are a good way to capture it in schemas."
HT: Maybe we should encourage the CDF and Schema WGs to come to consensus on the applicablity of substition groups for CDF?
TVR: Kevin Kelly is not only the WG chair, I know he did some work with schemas and WG.
DC: Dave or Noah, can you take the lead in contacting Kevin.
HT: Question is, are they using substitution groups, and why yes or no? Secondly, are there possibilities for discussion?
DC: Maybe better to just ask "what are you doing about versioning"?
DO: The TAG's been working on versioning and has a draft of an XML-related part of the finding. We solicit input on how part 2 of the draft finding stacks up with respect to what CDF is doing.
DC: Is the substitution group pattern in there?
DO: Substitution groups, yes. The pattern I'm not sure about.
DC: URI please?
<dorchard> http://www.w3.org/2001/tag/doc/versioning-xml#iddiv263689376
<DanC> http://www.w3.org/2001/tag/2006/10/04-tagmem-minutes#item05
DO: The part 2 draft is at http://www.w3.org/2001/tag/doc/versioning-xml#iddiv263689376
<timbl_> "This can only be used for incompatible extensions as the consumer must understand the new element and the schema that contains the substitution type."
DC: See also Vancouver minutes at http://www.w3.org/2001/tag/2006/10/04-tagmem-minutes#item05
HT: This is not the pattern. It's useful, but not the pattern we've been talking about. The Vancouver pattern was (what's the old TEI name?). Instead of writing content model for <p> as mixed over <b>,<i>, etc. You write a schema that says <p> is mixed over abstract element <slug>, with <b> etc being in the substitution group for <slug>. Anyone can add themselves to the group for <slug>.
TBL: What's the difference?
<DanC> (I think my msg http://lists.w3.org/Archives/Public/public-xml-versioning/2007Feb/0000.html captures the pattern HT just spoke of, to the resolution of 1 or 2 paragraphs)
HT: Examples 24 and 25 are taking an element that has a wildcard and making a new one that makes it more explicit. The <p> content model case is one in which the focus is upwards. I.e. what can you put into <p>. Another good example is <table> data. You could make <td> as abstract?
NM: Shouldn't it be a child of <td> that's abstract?
HT: No.
<noah_> Noah notes that he's not entirely convinced. The <td> needs to appear in the instance; it's the content that can vary, no?
TBL: That's not substitution groups?
HT: It's another style of using substitution groups.
DO: I need to get that into the finding. Would like to respond to this on the XML Versioning list.
<scribe> ACTION: Dave Orchard to draft discussion of using substitution groups for examples like HTML <p> mixed content and/or <td> content. [recorded in http://www.w3.org/2007/04/23-tagmem-irc]
DC: We will not have formal action on communicating with Kevin.
<Zakim> noah, you wanted to talk about schema 1.1
<DanC> NM: there's some stuff coming in schema 1.1 that pertains, directly and indirectly: (a) multiple inheritance with substitution groups, (b) changes to wildcards choice between subst. group head and lax wildcard is now possible, so you can get detailed evaluation of things added to the subst. group., but still allow other things
DC: Are the pertinent drafts public?
HT: Yes.
<DanC> NM and DO discussion details of schema 1.1 wildcard/subst and example 24/25...
DO: I was wondering about reviewing the versioning drafts. I'd like to talk about these the F2F.
DC: I have an action to review definitions of backwards/forwards compatible. You can expect me to do that.
<DanC> ACTION: DanC to Review definitions of partial understanding, backward compatible, and forward compatible. [CONTINUES] [recorded in http://www.w3.org/2007/04/23-tagmem-irc]
DC: I'll read more than that, but probably not a comprehensive review of the whole thing.
... How many pages to review?
DO: I get 20 pages for part 2.
NM: My fonts are a bit larger. I get 30 pages for part 2.
DC: Norm, can you review the 2nd part?
NW: Yes, I'll do it.
DC: F2F starts May 31 and material is available now?
DO: Yes.
NW: I will review in time for telcon on 14 May.
... F2F is 30th of May?
DC: Yes, 30 May to 1 June.
<dorchard> http://www.w3.org/2001/tag/doc/versioning
<dorchard> http://www.w3.org/2001/tag/doc/versioning-xml
<DanC> http://www.w3.org/2001/tag/doc/versioning-xml 26 March 2007
<scribe> ACTION: Norm to review http://www.w3.org/2001/tag/doc/versioning-xml for discussion on 14 April telcon. [recorded in http://www.w3.org/2007/04/23-tagmem-irc]
DO: Note that I've given undated URIs, so these may change out from under us.
DC: I encourage you to keep a change log.
DO: OK, starting now.
DC: Noah, have you commented recently?
NM: I think it's been awhile. I did read recently, but honestly feel I've commented a lot the past 2 years and would like to hear from others.
... Still, I'll do it if you like.
DC: What's up with the comments from Rhys?
DO: I have not gotten them.
... He sent me something privately on Thursday 12 April, and I suggested he respond to public list.
DC: I see, he said he had comments, but did not include them.
DO: I replied on 23 April.
DC: Today?
DO: Yes.
NM: Is there a problem with using proprietary formats? I'll be glad to help convert to PDF.
DO: I've been thinking some on version ids in HTML and XHTML. I've been thinking that the version mapping is critical to forwards compatibility. Backwards is easier, because you can code to recognize old stuff.
... What seems to be the status quo is to use the letters "HTML" in the doctype. Leads me to wonder how a 5.1 or 6 would be identified.
... That's one of the reasons I've been thinking about this issue of version mapping.
... Dan, can you help me understand if they're worrying about forwards compatibility.
DC: Yes, it's very important, but it's also the sort of hard problem that is not going to be easy for the group to drive to consensus. There are strong pros and cons on both the "identify versions" and the "don't identify" sides.
TVR: I think there should be some sort of identifier in the DOM, and that it should be serialized.
DO: Has the mapping discussion come up in terms of making statements in advance about 5.1 and future versions.
DC: Yes, indeed debating such compatibility mechansisms is a central focus of the group, though the terminology used might not always be the same we use in the TAG.
DO: How do I find the discussion.
DC: See thread starting with a Chris Wilson message. It's pointed to from the WG homepage.
DO: I'll look.
DC: We will meet in one week with Rhys as scribe and Stuart as chair
(Scribe notes that this discussion actually occurred earlier, as an aside during the discussion of versioning. If you really care about where it occurred, check the IRC log.)
TVR: About the F2F. I need the names so we can have badges made.
HT: Since I can now tell you that I'm coming, I think that completes our group. I believe everyone is coming.
DC: adjourned