Lists Home |
Date Index |
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)" <firstname.lastname@example.org>
> 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.
> From: Pete Cordell [mailto:email@example.com]
> 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.)
for XML to C++ data binding visit