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