Actually these where the points I was trying to highlight in my
response, but I wanted specifically to remove it from the context of
XML because I think that , although the focus of such points in XML
are namespaces, the same issues would exist in other formats, only
they would perhaps move from the Namespace rules.

Cheers,
Bryan Rasmussen

On Dec 20, 2007 10:21 PM, Stephen Green <stephengreenubl@g...> wrote:
> Hi Roger
>
> A key factor is that of the namespace and I don't think anyone
> commenting in this thread has highlighted that yet
>
> On 20/12/2007, Costello, Roger L. <costello@m...> wrote:
> ...
>
> > CLARITY SOUGHT
> >
> > What does this mean: "The version management needs to be embedded in a
> > business process"?
>
> The business process will quite likely specify the documents being
> exchanged by their namespaces.
>
> The namespace may or may not include version identifiers.
>
> If there is an extension in a future, even a small one, what happens if
> 1. the namespace changes, perhaps to indicate and identify the new version
> 2. the namespace doesn't change
>
> In case 1. it may be that the business process will have to be updated
> but then what happens if old namespace documents are still be processed?
> Do you need then to support two processes? Can the documents be mixed?
> i.e. a process for an exchange of document A with document B and document
> A becomes document A2, can B still be used when A2 is used?
>
> In case 2. does the process support documents of any future version provided
> the namespace doesn't change? Isn't that inviting trouble? Can you say you
> will support a process which could change at any time whenever a new document
> version is introduced? Or do you want to specify the version in the business
> process definition, along with the namespace? If so, will you not then need to
> update the process and consider all the situations in case 1.?
>
> I'm not sure whether these are what was meant originally about version
> management being embedded in the process - but just to highlight what
> that might entail.
>
> I notice that the example below does not have a change of namespace
> because it does not have a namespace. This nicely avoids all sorts of
> real-life issues. Namespace/Version issue is a bit like the dll version issue
> and 'dll-hell'. With the dll version, it is registered in a registry; with the
> namespace/version it is detailed in a business process. The parallel includes
> constraints imposed on one consumer by another in that if the second
> consumer wants to use the next version then the business process spec may
> have to be changed but that needs to be done in a way that doesn't badly
> impact on the first consumer, say.
>
> >
> > VALIDATE NEW DATA AGAINST OLD SCHEMA
> >
> > Validation of the new data against the old XML Schema will result in
> > validation errors.
> >
>
>
> > ----------------------------------------------
> > CDC VERSION 1 SCHEMA
> >
> > <?xml version="1.0"?>
> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> >         elementFormDefault="qualified">
> >     <element name="deaths">
> >         <complexType>
> >             <sequence>
> >                 <element name="heart-disease" type="unsignedInt"/>
> >                 <element name="cancer" type="unsignedInt"/>
> >                 <element name="stroke" type="unsignedInt"/>
> >                 <element name="chronic-lower-respitory-diseases"
> > type="unsignedInt"/>
> >                 <element name="accidents" type="unsignedInt"/>
> >                 <element name="diabetes" type="unsignedInt"/>
> >                 <element name="alzheimers" type="unsignedInt"/>
> >                 <element name="influenza-and-pneumonia"
> > type="unsignedInt"/>
> >                 <element
> > name="nephritis-and-nephrotic-syndrome-and-nephrosis"
> > type="unsignedInt"/>
> >             </sequence>
> >             <attribute name="year" type="gYear"/>
> >             <attribute name="source" type="anyURI"/>
> >         </complexType>
> >     </element>
> > </schema>
> >
> > CDC VERSION 2 SCHEMA
> >
> > <?xml version="1.0"?>
> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> >         elementFormDefault="qualified">
> >     <element name="deaths">
> >         <complexType>
> >             <sequence>
> >                 <element name="heart-disease" type="unsignedInt"/>
> >                 <element name="cancer" type="unsignedInt"/>
> >                 <element name="stroke" type="unsignedInt"/>
> >                 <element name="chronic-lower-respitory-diseases"
> > type="unsignedInt"/>
> >                 <element name="accidents" type="unsignedInt"/>
> >                 <element name="diabetes" type="unsignedInt"/>
> >                 <element name="alzheimers" type="unsignedInt"/>
> >                 <element name="influenza-and-pneumonia"
> > type="unsignedInt"/>
> >                 <element
> > name="nephritis-and-nephrotic-syndrome-and-nephrosis"
> > type="unsignedInt"/>
> >                 <element name="septicemia" type="unsignedInt"/>
> >             </sequence>
> >             <attribute name="year" type="gYear"/>
> >             <attribute name="source" type="anyURI"/>
> >         </complexType>
> >     </element>
> > </schema>
> >
> >
> > _______________________________________________________________________
> >
> > 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
> >
> >
>
>
> --
> Stephen Green
>
> Partner
> SystML, http://www.systml.co.uk
> Tel: +44 (0) 117 9541606
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>
> _______________________________________________________________________
>
>
> 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
>
>