RE: (Partial) review of Versioning XML

Again, great comments.  I've done most of them, and commented inline. 

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Norman Walsh
> Sent: Sunday, May 13, 2007 2:06 PM
> To: www-tag@w3.org
> Subject: Re: (Partial) review of Versioning XML
> 
> Here's the rest of my review.
> 
> > 7 Schemas for Version Identification Strategies
> >
> >   7.1 #1: all components in new namespace(s) for each version
> [...]
> >    The author has 5 options for the v2 schema for name and 
> middle, listed
> >    below and detailed subsequently:
> >
> >     1. optional middle, extensibility retained, but new 
> name type does not
> >        refer to middle;
> >
> >     2. optional middle, extensibility is lost, new name 
> type refers to
> >        middle;
> >
> >     3. required middle, extensibility retained, new name 
> type refers to
> >        middle but compatibility is lost (essentially strategy #1);
> >
> >     4. optional middle, extensibility retained, no new name type
> >
> >     5. no update to the Schema
> 
> I think it would be good to provide a little bit more 
> explanation of these five options. I'm not confident I 
> understand all of the distinctions from just this one 
> sentence explanation.

OK, I tried to add a bit.  But the explanations are somewhat complicated
so I didn't want to repeat all the possible designs shown later..

> 
> [...]
> >     7.2.1 Redefine
> >
> >    Redefine allows incompatible and incompatible changes to 
> be made to a
> >    type. This can be very dangerous because a document 
> cannot use namespaces
> >    or names to indicate which type is being used, either 
> the original or the
> >    redefined.
> 
> I think this would be better stated as:
> 
>      Redefine allows both compatible and incompatible changes to be
>      made to a type. Unlike other schema extension mechanisms which
>      provide new names for extended or restricted types, redefine
>      changes the definition of a type without changing its name. This
>      means that the name alone is no longer sufficient to determine of
>      two types are really the same.
> 

Done

> >    The schema author must take extreme caution to ensure that
> >    compatible changs are made.
> 
> I think "very dangerous" and "extreme caution" are perhaps a 
> little too strong.

Very dangerous is removed and extreme caution is replaced with some
caution.

> 
> [...]
> >   7.3 #3: All new components in existing or new 
> namespace(s) for each compatible
> >   version
> >
> >    It is possible to create Schemas with additional 
> optional components. This
> >    requires re-using the namespace name for optional 
> components and special
> >    schema design techniques. The re-using namespace rule is:
> >
> >    Good Practice
> >
> >    Re-use namespace names Rule: If a backwards compatible 
> change can be made
> >    to a specification, then the old namespace name SHOULD be used in
> >    conjunction with XML's extensibility model.
> >
> >    It is important to note that that a new namespace name 
> is not required
> >    whenever a specification evolves - strategies #1 and #2 
> - but rather a new
> >    namespace name can be required only if an incompatible 
> change is made.
> 
> Required here is a policy decision, yes? I could make an 
> incompatible change without changing the namespace, but 
> you're asserting that I should not do that, right?

Good point.  I've tried to clarify that in:
Strategy #1 uses a new namespace for all existing components and any
additions, strategy #2 uses a new namespace for all additions
(compatible and incompatible).  strategy #3 re-uses namespaces for
compatible extensions and uses a new namespace for all incompatible
additions.  Said slightly differently, strategies #1 and #2 use a new
namespace name for any extension and strategy # 3 uses a new namespace
only for incompatible change is made.  
> 
> >    Strategy #1 uses a new namespace for all existing 
> components and any
> >    additions, Strategy #2 uses a new namespace for all 
> additions. Strategy #3
> >    re-uses namespaces for compatible extensions.
> >
> >    Good Practice
> >
> >    New namespaces to break Rule: A new namespace name is 
> used when backwards
> >    compatibility is not permitted, that is software MUST 
> break if it does not
> >    understand the new language components.
> 
> I think it might be clearer to say must reject. And do we 
> really mean must?
> Certainly in some contexts it might be necessary to abort, 
> but I'm not sure that's true in all contexts.

OK, how about SHOULD reject texts...

> 
> [...]
> >    Example 19: New components in existing or new 
> namespace(s) with version
> >    identifier instances
> >
> >  <personName xmlns="http://www.example.org/name/1" version="1.0">
> >    <given>Dave</given>
> >    <family>Orchard</family>
> >  </personName>
> >
> >  <personName xmlns="http://www.example.org/name/1" version="1.0">
> >    <given>Dave</given>
> >    <family>Orchard</family>
> >    <middle>Bryce</middle>
> >  </personName>
> >
> >  <personName xmlns="http://www.example.org/name/1" version="1.1">
> >    <given>Dave</given>
> >    <family>Orchard</family>
> >    <pref1:middle 
> > xmlns:mid1="http://www.example.org/name/mid/1">Bryce</pref1:middle>
> >  </personName>
> >
> >  <personName xmlns="http://www.example.org/name/1" version="1.0">
> >    <given>Dave</given>
> >    <family>Orchard</family>
> >    <pref2:middle 
> > xmlns:mid2="http://www.example.org/name/mid/1">Bryce</pref2:middle>
> >  </personName>
> >
> >  <personName xmlns="http://www.example.org/name/1" version="2.0">
> >    <given>Dave</given>
> >    <family>Orchard</family>
> >    <pref1:middle 
> > xmlns:mid1="http://www.example.org/name/mid/1">Bryce</pref1:middle>
> >  </personName>
> >
> >    The last example shows that the middle is now a 
> mandatory part of the
> >    name.
> 
> How does it show that?

Good point. "The last example shows a middle that is a mandatory
part of the name, which is indicated by the use of a new major version
number."


> 
> >    As with Design #2, the schema for the optional middle 
> cannot fully
> >    express the content model. A schema for the mandatory middle is
> >
> >    Example 20: New components in existing or new 
> namespace(s) with version
> >    identifier schema v2, incompatible change
> >
> >  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >        targetNamespace="http://www.example.org/name/1"
> >        xmlns:namens="http://www.example.org/name/1"
> >        xmlns:midns="http://www.example.org/name/mid/1">
> >
> >    <xs:complexType name="nameType">
> >      <xs:sequence>
> >        <xs:element name="given" type="xs:string"/>
> >        <xs:element name="family" type="xs:string"/>
> >        <xs:element name="middle" type="xs:string" minOccurs="0"/>
> >        <xs:element ref="midns:middle"/>
> >        <xs:any namespace="##other" processContents="lax"
> >                minOccurs="0" maxOccurs="unbounded"/>
> >      </xs:sequence>
> >      <xs:anyAttribute/>
> >    </xs:complexType>
> >
> >    <xs:element name="personName" type="namens:nameType"/>  
> > </xs:schema>
> 
> Shouldn't the version number be in the schema somewhere?

:-)  Crazy, how did I miss that????

> 
> [...]
> >    This is not a very helpful XML Schema change. The 
> problem is that they
> >    cannot insert the reference to the optional midns:middle 
> element in the
> >    name schema and retain the extensibility point because of the
> >    aforementioned Non-Determinism Constraint.
> 
> I think it would be more helpful to refer to the determinism 
> constraint using the Schema terminology throughout. Yes, 
> "unique particle attribution" constraint is a jargony 
> mouthful, but using other terminology just raises the 
> possibility of confusion.

OK.

> 
> [...]
> >   9.1 DocBook
> >
> >             Requirement
> >             Schema Lang          RelaxNG
> >     3rd party compatibly extend  Yes
> >    3rd party incompatibly extend No
> 
> Third parties can make incompatible changes.

How do they do this?  I've changed it, but I'm curious.

> 
> >    Designer incompatibly extend  Yes
> >             stand-alone          Yes
> >            Schema design         Wildcards
> 
> There are wildcards, but wildcards and other XML Schema 
> design mechanisms don't translate to RELAX NG in a very 
> direct way. Changing RELAX NG patterns is perhaps more like redefine.
> 

I changed to "open content, patterns"

> >       Substitution Mechanism     Ignore Uknowns
> 
> It's only "ignore unknowns" in a few specific contexts. 
> Mostly, you're expected to understand all the extensions.
> 

Ok, changed to N/A

> >                                  Strategy #5 all components 
> in existing
> >      Component Identification    namespace(s) for each 
> version (compatible
> >                                  and incompatible) and a 
> version identifier
> >          Incompatible Ext        No
> >           identification
> >         Schema Completeness      N/A
> 
> [...]


<snip/>

> Well, if you're using XSD... :-)
> 
> > 11 Other technologies
> 
> Yes, we really do need to cover these in more detail.
> 
>                                         Be seeing you,
>                                           norm
> 
> --
> Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
> http://nwalsh.com/            | possible, but no simpler.
>

Received on Friday, 18 May 2007 04:46:32 UTC