[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [xml-dev] Interesting pair of comments (was Re: [xml-dev] Schema Experience Workshop minutes online)
Relevant to our discussions. ATG has decided to eliminate nqmespace versioning for minor version changes.
Mark R. Crawford
Senior Research Fellow - LMI XML Lead
W3C Advisory Committee and OASIS Representative,
Vice Chair - OASIS UBL TC
Vice Chair - UN/CEFACT Applied Technologies Group
Chair - UN/CEFACT XML Syntax Working Group
Co-Chair ISO TC154 Subcommittee for ISO 15000-5
--
LMI Government Consulting
2000 Corporate Ridge
McLean, VA 22102-7805
703.917.7177 Phone
703.655.4810 Wireless
The opportunity to make a difference has never been greater
www.lmi.org
-----Original Message-----
From: Pete Cordell <petexmldev@tech-know-ware.com>
To: Bullard, Claude L (Len) <len.bullard@intergraph.com>
CC: xml-dev@lists.xml.org <xml-dev@lists.xml.org>
Sent: Wed Jul 13 14:43:34 2005
Subject: Re: [xml-dev] Interesting pair of comments (was Re: [xml-dev] Schema Experience Workshop minutes online)
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 :-)
Pete.
----- Original Message -----
From: "Bullard, Claude L (Len)" <len.bullard@intergraph.com>
> 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@tech-know-ware.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.)
>
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx
(or http://www.xml2cpp.com)
=============================================
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]