Re: How to Version XML Applications

/ Joseph Reagle <reagle@mit.edu> was heard to say:
| I'm witnessing (and participating in!) a recurring discussion both within 
| [1] and without [2] the W3C about how to version XML applications. Some 
| like to continue the Major/Minor versioning from older formats; others 
| (including myself) like a NS based extensibility and versioning (with an 
| option to schema types and extension is you want to do something fancy), 
| and others are now proposing hybrids.

I assume by NS-based extensibility you mean changing the namespace
name. That bothers me because it completely changes all the names. The
difference between a:foo and b:foo is as dramatic as the difference
between foo and bar to namespace-aware software.

| On this note, XSLT was recently cited 
| and I find it's text on this matter to be confusing given a presumption 
| that other element types might be added to a REC's existing namespace. 
| Could the XSLT editor's shed some light on whether this approach is 
| presently being used?

I'm not the XSLT editor (and I don't even play him on TV), but I'll
take a stab at it anyway.

The XSLT vocabulary uses a required version attribute to identify the
version of XSLT. This allows existing XSLT processors to continue to
recognize the names of elements and attributes defined by XSLT while
simultaneously invoking appropriate fallback behavior if they
encounter an element or attribute in the XSLT namespace with a
local-name that is not recognized.

This does impose a constraint on the development of XSLT: the semantic
of existing names can't change.

| Also, would the TAG like to make some recommendations on this issue: either 
| technical, or recommending this be a work item of an existing WG?

I doubt that there's "one true solution" to this problem, so I'm not
inclined to encourage the TAG to get involved.

| Subject: Re: [RSS-DEV] restructuring Purls to reflect version number?
| Date: Wed, 11 Sep 2002 09:48:16 -0400
| From: Joseph Reagle <reagle@mit.edu>
| To: rss-dev@yahoogroups.com, Ian Graham <ian.graham@utoronto.ca>
|
| On Wednesday 11 September 2002 08:36 am, Ian Graham wrote:
|> IMHO, changing the nsURL declares a major change, and by
|> implication states that code supporting the old NS does
|> not support the new one. That's exactly how things work
|> with XSLT -- if you change the nsURI, then existing XSLT
|> code is completely broken.
|>
|> XSLT examples I've seen use version attributes (or other
|> such mechanisms) to trigger alternate processing dependent
|> on the attribute value, within the context of a given
|> namespace.
|
| I'd be careful about relying upon XSLT as a case of best or even common
| practice at the W3C with respect to versioning. In fact, the sentence
| "Thus, any XSLT 1.0 processor must be able to process the following
| stylesheet without error, although the stylesheet includes elements from
| the XSLT namespace that are not defined in this specification:" My
| understanding of the present W3C's understanding <smile/> is that the XSLT
| Recommendation is the exclusive and complete definition of that namespace.

I think I'd state that slightly differently. The XSL WG holds
exclusively the rights to modifying the members of that namespace. Any
given Recommendation from the XSL WG contains a complete definition of
one version of that namespace.

You can't invent xsl:my-favorite-tag, but the XSL WG can.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM    | 'tis expressly against the law of arms: 'tis
XML Standards Architect | as arrant a piece of knavery, mark you now,
Sun Microsystems, Inc.  | as can be offer't; in your conscience, now,
                        | is it not?--Fluellen, Henry V

Received on Wednesday, 11 September 2002 10:20:10 UTC