OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Versioning of Enums

[ Lists Home | Date Index | Thread Index ]

At 2006-02-13 22:00 +0000, Fraser Goffin wrote:
>this :-
>>I am in the camp that believes if you change the schema for a 
>>document you have to change the >version of the schema. If you 
>>change the version of the schema, you change the namespace of >the document.
>This appears to imply that you are in the camp that believes that no 
>schema change can be made without changing the namespace.  That is, 
>there is no extensibility, there is no distinction between minor and 
>major change, and no possibility of making forward/backwards 
>compatible changes that don't effect the namespace (as described in 
>David Orchard's series of articles) ?

Sorry, I have no problems with backwards compatibility ... 
restricting a schema is fine with me without changing the namespace 
since instances of the restricted schema validate with the base schema.

Where a namespace has to change (in my opinion) is when any instance 
of a new schema is not a valid instance of an old schema.

>I admit to being in the camp that says the addition of a new value 
>to an enum does NOT warrant a new schema namespace (subject to the 
>usual caveats about semantic coherence) ?

Fine ... but what if my system cannot accommodate your new 
value?  You'll need a business rule for interoperability describing 
what a recipient does with an instance whose value is rejected by 
their version of the schema.  And how would you manage the exchange 
of schemas if you have a new set that you send to a recipient, but 
that recipient has their own set of extended schemas.  All of which 
have the same URI namespace, yet the base schemas distributed by a 
central authority don't pass any of the instances with the extended values.

Yes, there are similar issues dealing with any expression of value 
validations layered on top of the schemas, but the management of the 
schemas is taken out of the equation.  Those are unequivocally 
identified and easily managed.

But "ease" is subjective here ... many people do very fancy things 
with schema expressions.  But regardless, taking a layered approach 
gives the flexibility of having different "second layers" built on 
top of a base layer.

>I'm a bit reluctant in the area of validating instances based on 
>caller assertions. For example, some instance docs arrive with an 
>xsi:schemaLocation attribute value, but I tend to feel that I would 
>prefer validation to execute against schema that I am in possession of.

I totally agree.  Note that not many W3C Schema tools let you easily 
ignore the schemaLocation hints ... I have found Norm Walsh's 
http://nwalsh.com/java/xjparse/index.html to be very helpful because 
I can do W3C Schema validation of an instance with a command-line 
invocation of the schema expression file (ignoring the schemaLocation hint).

>Likewise (perhaps) with the version attribute you mention (but less so).

Yet the life cycle of a set of enumerations in a code list (a 
one-dimensional construct) could be easier to comprehend and work 
with than the life cycle of interacting schema fragments.  But you 
are right, not by much.

>Since the creation of document instances is a little more complex my 
>guess is most will not bother with this and those that do will 
>probably let them get out of date. Thats evidence of the cynic in 
>me, but there is a basis of experience of organisations trying to 
>construct even relatively trivial XML messages (hence why many 
>schema are defined as elementFormDefault='unqualified'). We must 
>remember that many callers may have extremely limited IT resources, 
>so simpler is often better (even if its less precise).

I'm not sure where in that discussion you are attributing the 
"simpler" ... I'm guessing the business users utilizing UBL (or any 
other domain document model) will more easily comprehend the inputs 
to a value validation layer built on top of structural validation set 
of schemas.

>>>2. I see mention of auditability and impact analysis but didn't 
>>>understand how these would be acheived. ?
>Yeh, sorry, these comments arose after reading Tony Coates's doc :-

Oh, of course, and yes I agree with Tony that genericode is evolving 
to meet these objectives but he's the business expert with respect to 
using code lists ... I'm just the geek that is trying to implement it 
in a way that makes sense for UBL (and, I'm hoping, for other users 
of Tony's code list implementation).  I'm focused on the 
implementation of their use, Tony has put the thought into the 
business needs of code lists as artifacts themselves.

>Reaching Consensus on Code Lists - London Market Systems - OASIS 
>Symposium 2005, New Orleans
>In it there were comments such as :-

He has been gleaning his requirements from a number of projects 
dealing with code lists.

>I guess I took from this that genericode would enable me to track 
>changes across subsequent versions of code list definitions,

I understand that he has addressed such issues.

>and possibly assess how a new change impacts the existing code list 
>definitions (and possibly to the applications and/or Trading Partner 
>agreements using them). But maybe I am reading in something that isn't there.

No, no ... that *is* where Tony is going with having a standalone 
expression of coded values:  interchange (I might maintain the list 
in a database table but I can use genericode to move it from one 
database to another), identification (the country subentity codes of 
Canada vs. the country subentity codes of the US), maintenance (XML 
instance maintenance), etc.

>>It is the purview of the UBL committee to dictate the structure of 
>>UBL documents for interoperability of the instances.  It is the 
>>purview of trading partners to agree on the layer of value 
>>validation placed on top of the standardized structures that are 
>>under their control in doing business.
>Yes, I like this statement. But with the proviso that anything 
>offered by the standards body does not interfer, constrain or make 
>more difficult, the business operations of any participant (IMO as 
>soon as that happens, TPs will go 'private').

Absolutely!  Hence (I believe) the approach of using layered value 
validation on top of structural schemas provides the balance for UBL 
of the committee constraining the structure of the documents and the 
users describing through genericode their own context of values for 
the controlled vocabularies.

>>I believe if trading partners have to "compromise" the standardized 
>>structures by building in the business rules of value validation, 
>>they run the risk of having different schema expressions expressing 
>>the same "structure of a UBL 2.0 document".  With careful 
>>management it can surely be done ... but I'm concerned about the 
>>integrity of saying "my modified W3C schema expressions conform to 
>>UBL 2.0 ... trust me!"
>OK, thats a valid point of view. But cannot the same argument be 
>made for the possible mis-use of enumerations which purport to be a 
>valid subset of some standard set, or if extended, 'I can guarantee 
>the semantic coherence of the new values ... trust me :-). Why are 
>structures special in this regard. Both the structural context and 
>reference data are of equal importance aren't they ?

That's not *quite* my point ... I'm more worried about compromise 
through inadvertent schema changes than I am about managing the set 
of validation values and their associated semantics.

The code list context association file in our methodology points to 
the genericode files ... the combination describes the validation 
layer ... that combination can be documented, packaged, interchanged 
and used without making any changes at all to the standardized 
structural schemas.

>>The former ... that no enumeration could be considered stable for 
>>the long run.  Business has been flexible for thousands of years 
>>... introducing constraints on what two trading partners wish to 
>>agree upon seems arrogant ...
>But aren't you proposing no flexibility (extensibility) within the 
>structural specification whatsoever outside of the timetabled 
>'round' for requesting changes ??

Other people better than me are looking at UBL Contextualization and 
what it means to accommodate users needs for structural validation 
beyond what the committee has produced.  My gut feel is that ISO/IEC 
19757-4 NVDL could play an important role in this, but with my UBL 
volunteer time focused on code lists, the HISC committee and the SBSC 
committee, I just don't have the time to look at that as well.

>Hope I'm not sounding too negative, just trying to get things 
>arranged in my mind :-)

Not at all!  Hope I'm not sounding too much like pontificating about 
what I'm trying to accomplish for UBL.

Thanks for the dialogue, Fraser,

. . . . . . . . . . . . . Ken

Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-03-13/17
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS