Altova Mailing List Archives

Re: [xml-dev] Interesting pair of comments (was Re: [xml-dev] Schema Experience Workshop minutes online)

From: "Pete Cordell" <petexmldev@--------------.--->
To: "Bullard, Claude L \(Len\)" <len.bullard@----------.--->
Date: 7/13/2005 6:44:00 PM
Dear Len,

I sense that this is a wider debate that I'm naively wading into here, and I 
think your primary application domain is different to mine.  But (most 
likely telling you things you already know)...

In a protocol / data oriented world, when you up issue, the ideal would be 
to leave the targetNamespace URI (I assume that's the URI you're talking 
about) the same and possibly change the xs:schema version attribute (for 
info).  Any XML instances generated against the old schema would also be 
valid against the new schema.  Thus, in my selfish application domain this 
is not a problem.

To end with a slightly emotive statement, there is no point in worrying how 
you are going to identify an up-issued schema if you can't generate one (or 
at least, the one you want) in the first place :-)


----- Original Message ----- 
From: "Bullard, Claude L (Len)" <len.bullard@i...>

> If this were only a problem of XSD, I wouldn't be
> as concerned, but the problem as someone else pointed
> out is more fundamental.  The URI mechanism really
> falls apart in the face of identifying dynamic
> systems as resources in the abstract although
> we get away with it using code and error messages
> to soak up the gaps (indirection to the rescue).
> At some point, we have to face up to some issues that
> unsettle what Richard Dawkins calls 'middle reality'
> and understand their impact:
> 1.  Declarative systems are limited when it comes to
> describing dynamic systems.
> 2.  Namespaces are inadequate to identify dynamic
> systems.  I may crack wise about black holes and
> quantum mechanics, but the opaqueness of URIs makes
> them unsuitable for identifying dynamic systems to
> external observers.  An identifier that has to account
> for change has to be, itself, a resource, given the
> current 'middle reality'.
> The effects of using them are almost precisely the
> same as watching a traveler cross an event horizon.
> The time is infinite as the traveler approaches and no change
> past the horizon is observable.  Thus other than a
> syntax for disambiguating nodes within an instance,
> they are virtually useless unless one breaks the rules
> of the 'middle reality' of URI opacity.
> It is time to realize that names and identifiers
> and locations are not the same, and where we indulge
> in that 'middle reality', we ignore the very real
> problems they create by pretending to solve problems
> they don't touch.   We could think about using URNs
> as non-opaque resources and use URIs only as abstract
> identifiers (in the same way an event boundary has
> area but no volume).  However, then we either have
> to admit a URN is NOT a URI or remove the opaqueness
> restriction on URIs, or dump the notion and admit
> that RDDL, catalogs, etc. aren't a nice to have but
> a must have.
> len
> From: Pete Cordell [mailto:petexmldev@t...]
> I'm not sure whether this comes under more digging, or clarification,  but
> coming from a data-oriented / protocol background I would like to see a
> better story on versioning with some urgency.  I see a number of schemas
> that either won't be versionable, or will get very ugly when versioned.
> (Extending enumerations is an example of the former, and naively extending
> elements is an example of the latter.)
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.