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

Title: 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 <>

To: Bullard, Claude L (Len) <>

CC:  <>

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)" <>

> 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:]

>

> 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>