[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Changing Namespaces Between Specification Versions

  • From: David Orchard <orchard@p...>
  • To: Fraser Goffin <goffinf@g...>
  • Date: Thu, 23 Apr 2009 21:37:22 -0700

Re: Changing Namespaces Between Specification Versions
Thanks for the mention fraser.  Some of the works that I've done have
been on the TAG at
http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies
covers much of this.

Personally, I like the idea of using the namespace name to indicate
incompatible changes and version #s to indicate compatible changes.

The issue of multi-namespaces and appropriate version #s is very
difficult.  What is the version of a doc that contains n different
namespaces, each which may be versioned compatibly and retain their
namespaces?  Do we have to have a version # that is a composite of the
union of all the namespaced items that may be present in the document?
 In my mind, a version # or a namespace on a root element is most
useful for advance warning to a consumer about what to expect in the
document.  However, that only works in some situations, typically when
machines have generated the namespace or version number.  HTML has
proven that any version identifier created by humans is highly prone
to error and ultimately ineffective.

Cheers,
Dave

On Thu, Apr 23, 2009 at 12:26 PM, Fraser Goffin <goffinf@g...> wrote:
> And adding to this point, Ken mentioned earlier that the processing of
> an instance could 'strip  off' information items that it isn't
> prepared/able to process. Whilst a this can work in the request phase
> of a message exchange, what about the response. Imagine a v2 XML
> instance arrives at a v1 processor. The processor removes all the v2
> stuff it doesn't understand, does its work and then constructs the
> response. But the caller is expecting a v2 response and it contains
> information items which the v1 application doesn't have, and it may
> well want some of the information items that were passed in on the v2
> request which were discarded as well.
>
> On the later point, David Orchard, sometimes refers to the ability of
> a process to ignore data it doesn't understand as the 'must ignore
> pattern'. But there are 2 flavours of this, 'must ignore retain' and
> 'must ignore discard'.
>
> And since Ken introduced the idea, there might also need to be a
> 'retain' step prior to any removal of data for legal, regulatory and
> sometimes business audit / non repudiation reasons.
>
> Following the debate that an earlier poster referred to, also
> mentioned the use of a validator, and the meaning was not necessarilly
> meaning XML schema validation. In many circumstances both XSD itself
> and validation against XSD is just too brittle.
>
> Fraser.
>
> 2009/4/23 Andrew Welch <andrew.j.welch@g...>:
>>>> How does the
>>>> receiver determine the appropriate schema when the version is not
>>>> explicitly referenced?
>>>
>>> Why not "try one and if it fails try the other"?
>>
>> There is a problem with this - the document is a v2 doc but fails for
>> some reason, so validation falls back to the v1 schema, which also
>> fails... which error message gets presented to the user?
>>
>> You want the v2 failure message, but the system can't confidently give you that.
>>
>>
>>
>>
>> --
>> Andrew Welch
>> http://andrewjwelch.com
>> Kernow: http://kernowforsaxon.sf.net/
>>
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@l...
>> subscribe: xml-dev-subscribe@l...
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.