[
Lists Home |
Date Index |
Thread Index
]
Ken,
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) ?
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) ?
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. Likewise
(perhaps) with the version attribute you mention (but less so). 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).
>>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 :-
Reaching Consensus on Code Lists - London Market Systems - OASIS Symposium
2005, New Orleans
In it there were comments such as :-
'There needs to be an audit trail'
'This means that the code list model needs to model the ways that code lists
are modified'.
'It also needs to be clear how to regenerate a derived code list when the
underlying code lists change'
'Relationships between code lists are auditable, and derivations are
repeatable'
I guess I took from this that genericode would enable me to track changes
across subsequent versions of code list definitions, 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.
>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'). A standards' value is in its pervasiveness. As we know
there are many 'de facto' standards which have never been within 'cooeee' of
any of the 'official' ratification bodies, and plenty that have that are
gathering dust. That said, I am a supporter of standards since this is the
only realistic path the broad interoperability and it associated benefits,
but I believe my point still stands (as you comment later, it is arrogant to
second guess business use and folly to try and control it (I added that
bit).
>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 ?
>Oh, one more thing ... my approach allows two different contexts of the
>same information item to have two different sets of coded values
Yep, agree, this *is* a definate advantage.
>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 ??
Hope I'm not sounding too negative, just trying to get things arranged in my
mind :-)
Fraser.
>From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
>To: XML-Dev Mailing list <xml-dev@lists.xml.org>
>Subject: Re: [xml-dev] Versioning of Enums
>Date: Mon, 13 Feb 2006 09:24:54 -0500
>
>At 2006-02-13 12:26 +0000, Fraser Goffin wrote:
>>some 'at first glance' questions. If these seem a bit dumb, please take
>>them as an oppotunity to promote the strengths of this approach :-
>
>All questions are welcome, Fraser!
>
>>1. How does this approach specifically assist in dealing with versioning
>>issues ?
>
>Code list versioning is a shared responsibility between describing the code
>list, associating the code list, and using the code list. UBL provides
>code list meta data attributes that a user can choose to use. genericode
>provides for indicating the version of an expression of code list values.
>
>In a UBL instance a user can say the following, indicating that the version
>of the code they are using is not important to them:
>
> <cbc:AccountTypeCode>ABC</cbc:AccountTypeCode>
>
>Alternatively, if the version is important they could say:
>
> <cbc:AccountTypeCode listVersionID="3.7">ABC</cbc:AccountTypeCode>
>
>A genericode expression of values includes the version of those values.
>
>A code list context association file could have the union of a number of
>genericode files that trading partners wish to use:
>
> <Context item="AccountTypeCode" codes="atcV3-6 atcV3-7"/>
>
>My scripts will check the authored content for a version number and, if not
>present, will check the value given against all values of all associated
>code lists (since version isn't indicated, all are in play). When present
>it will limit the checks against only the code list with the same version
>number as @listVersionID. If no associated genericode code list has the
>version number indicated in the UBL instance, then the value violates the
>constraints expressed in the triad of description, association and use, and
>an error is reported.
>
>>2. I see mention of auditability and impact analysis but didn't understand
>>how these would be acheived. ?
>
>Could that have been in another document? I don't mention either of those
>terms explicitly in my document. I think my discussion above regarding
>sensitivity to versions of code lists would handle auditability. I'm not
>sure what you mean by impact analysis.
>
>>3. How is this approach 'better' than creating a vocabulary schema for
>>each third party contract using the 'chameleon' schema +
>>xs:redefines/union/restrition etc. I mentioned earlier (I take the point
>>about being able to specify particular contexts in which an enumeration
>>can apply - but is there more ?)
>
>By not conflating value validation with structural validation.
>
>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. Otherwise, two trading
>partners could inadvertently be saying "I use UBL 2.0" when they are, in
>fact, using different sets of schemas that are indicating the same
>namespace URI string.
>
>By layering value validation on top of structural validation, business
>constraints on values don't impact on the declared structure of the
>document.
>
>Now one could say they have the same problem saying "I'm using the
>following association files" when in fact they are not ... but that is a
>management issue in that they interchange the layer on top of the
>standardized W3C Schema expressions. Which then leads to the question of
>"why not just interchange the agreed on W3C Schema expressions? ... how is
>that different?"
>
>I believe they really are different ... structural schemas are (should be
>in my opinion) inviolate. Granted some inviolate enumerations are required
>by UBL *by design of UBL* and are not subject to trading partner
>interpretation. Not all enumerations are business related code lists. I
>do believe that a structural schema can express an enumeration of values
>that are inherent in the design of the information structure.
>
>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.
> They do not have the authority to mess around with the fixed enumerations
>designed in as part of UBL's internal design.
>
>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!" With my proposed
>methodology I can categorically say "I am using the sacrosanct UBL 2.0
>document structures" and then just focus on ensuring you and I agree on the
>layer of value validation placed on top.
>
>By not conflating business rules with standardized structure, the standards
>committee's efforts to produce a set of structures to be used by all is
>incredibly enhanced because nobody has to touch them in any fashion in
>order to become fully interoperable at a business level as well as a
>structural level. And the enumerations needed in the design of UBL not
>related to business rules remain sacrosanct and trading partners cannot
>extend them and possibly break UBL implementations (though they could be
>restricted if trading partners wish to agree on subsets of UBL invocation
>somehow).
>
>YMMV in this regard, but it is a position I have long held (for good or
>ill) and I always try to find ways to deal with read-only distributions of
>agreed-upon issues.
>
>Finally, one could refute the above with a pure W3C Schema approach stating
>"well, I'll use inviolate UBL 2.0 for a W3C Schema first pass and then my
>favourite W3C Schema method of implementing code list values in a modified
>W3C Schema second pass for code lists" ... all power to you, but I think
>the elegance in genericode expression and management, and the flexibility
>in associating sets of values with contexts is easier to manage, easier to
>understand, and easier to introduce into a trading partner agreement.
>
>Oh, one more thing ... my approach allows two different contexts of the
>same information item to have two different sets of coded values (see the
>example in sectoin 6.1 regarding the "item-b" information item) ... how
>could I do that with W3C Schema expressions when they do not support
>co-occurrence constraints? I'm effectively saying that element item-b
>(which is globally declared in UBL) has two sets of values (two types)
>based on its parent.
>
>>4. Large lists are still a problem right ?. It is not unusual in the
>>financial services sector for many lists to be > 200 entries, a reasonable
>>number to be > 1000 and a few that are >10,000. Using schematon XSLT would
>>be a bit impractical wouldn't it ?
>
>Would two trading partners have to agree on all 10,000 being available to
>engage in business?
>
>Would such number constraints be less impractical in a W3C expression of
>10,000 enumerations?
>
>A genericode file could be synthesized from a database query of which of
>the 10,000 would be appropriate for a particular department or line of
>business. I suppose a database query could also synthesize a W3C Schema
>fragment.
>
>Note that XSLT is but one implementation of ISO/IEC 19757-3 Schematron ...
>now that it is ratified as an ISO standard vendors might explore more
>high-speed implementations and customers with requirements to support
>10,000 values being validated might pressure vendors to consider finding
>high-speed solutions to such issues.
>
>>4. You mentioned in your earlier response to Glen, that you had hoped in
>>UBL to remove ALL embedded enumerations from schema.
>
>Indeed ... the presence of any embedded enumeration constraints of
>business-related concepts when using this methodology would only give
>benefits of agreeing on a subset of the declared list rather than a
>flexible list of any set of values.
>
>>Did you decide then that no enumeration could be considered 'stable' or
>>did you want this just to keep the approach consistent regardless ? (you
>>also mention 'type 1' code lists which suggest in schema definition ?)
>
>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
>... I anticipate trading partners to be far more imaginative in doing
>business than UN/CEFACT or UBL or anyone could bring down by edict.
>
>I hope this helps. Thanks again for your questions!
>
>. . . . . . . . . . . . . . . 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
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
|
