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

Re: Data versioning strategy: address semantic, relationship,

• From: "Stephen Green" <stephengreenubl@g...>
• To: "Costello, Roger L." <costello@m...>
• Date: Thu, 20 Dec 2007 21:21:55 +0000

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

• Follow-Ups:
  • Re: Data versioning strategy: address semantic, relationship, and syntactic changes?
    • From: "bryan rasmussen" <rasmussen.bryan@g...>

• References:
  • Data versioning strategy: address semantic, relationship, and syntactic changes?
    • From: "Costello, Roger L." <costello@m...>
  • RE: Data versioning strategy: address semantic, relationship, and syntactic changes?
    • From: "Dave Orchard" <orchard@p...>
  • RE: Data versioning strategy: address semantic, relationship, and syntactic changes?
    • From: "Costello, Roger L." <costello@m...>