[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Code list extensibility and substitution groups
Thanks for you note, David. You may have missed my point. I said I wasn't all that convinced code value constraint or extension was necessary anywhere other than in the application. If I were afraid of a "rat's nest of schema and overrides," it's safe to say adding another complex layer of standards, like CAM, to the whole mess doesn't make it any more desirable! If I absolutely felt compelled to use schema to enforce a restriction of currency codes to Euros, Dollars and Pounds, then I can make do using "redefine." I have an example Purchase Order at http://www.novannet.com/cd-UBL-1.0/xml/office/UBL-Order-1.0-Office-Example-with-Bad-Currency.xml which uses an "override" of the UBL Order-1.0 schema. The "override" PO Schema, UBL-Order-1.0-Novannet.xsd, merely brings in my own currency list, UBL-CodeList-CurrencyCode-1.0.-Hard.xsd, in addition to the base UBL Order-1.0 schema. In turn, my currency schema simply redefines the standard UBL currency list to include only those three currency codes of interest (EUR, GBP and USD). When you bring my sample UBL-Order-1.0-Office-Example-with-Bad-Currency.xml into XMLSpy and validate it, the "bad" currency of Canadian Dollars (CAD) is duly noted. For such a small example, this doesn't seem like much of a "rat's-nest." Two small schema are used in addition to all the standard UBL 1.0 infrastructure. Using "redefine" in this way avoids the need to change any UBL document schemas at all. I haven't tried any analogs using the substitution group mechanism, but I imagine it can be made to work the same way. Nonetheless, I would still probably prefer to refer to the "virgin" UBL document schema in my instance data - with no subsetting or extension of standard code lists - and let my application do the validation for particular currencies that I actually support - i.e., move the business logic into the one place it makes sense: my application. William J. Kammerer Novannet Columbus, OH 43221-3859 . USA +1 (614) 487-0320 ----- Original Message ----- From: "David Webber (XML)" <david@drrw.info> To: "William J. Kammerer" <wkammerer@novannet.com>; <ubl-dev@lists.oasis-open.org> Sent: Friday, 18 February, 2005 09:41 AM Subject: Re: [ubl-dev] Code list extensibility and substitution groups William, Well put clarifications. I'm looking to paraphrase this here - if the schema contains the "all possible results set" - in terms of both the structure and the allowed values - then you can use tools like CAM to augment the schema and serve as the business agreement rules - that enforce the deltas. Ideally in an ebXML world this goes from the BPSS step that is identifying a business transaction document (in our case the UBL transaction) - with a context conditional of - majorCurrencyOnly - to the CPA agreement on service/actions between partners, to the ebXML envelope, that the ebMS then recognizes, and references the CPA isntance in the Registry - that then tells it that the validation script for that document type is the CAM template. As you point out - this avoids getting tangled in schema mechanics that are almost certain to be hard to diagnose or implement - and puts the logic where it needs to be as part of the business agreement layer - using the CAM template to capture that context and detail. Thanks, DW ----- Original Message ----- From: "William J. Kammerer" <wkammerer@novannet.com> To: <ubl-dev@lists.oasis-open.org> Sent: Friday, 18 February, 2005 08:15 AM Subject: Re: [ubl-dev] Code list extensibility and substitution groups I'm not going to outright disagree with my good friend David RRR Webber (I've promoted him to have 3 middle initials, 2 short of the future King). But I'm not sure "ad hoc extensibility of standard code lists [is] really a requirement." Putting aside versioning, if a value is constrained to contain an ISO 4217 currency code, then I rightfully assume any of its values can be used to form a valid document, for example. Now, it may be a business requirement that the supplier only accepts prices in USD and EUR, but it would be truly frustrating to have my XML tools or translator bark at me because I used GBP - what to me appears to be a perfectly sound, hard currency. It would be hard to trace back through the rat's nest of schema and overrides to see just why this is happening - why a valid ISO 4217 code is causing me conniptions. IF IT'S A PAROCHIAL BUSINESS REQUIREMENT, THEN SCHEMA DO NOT SEEM TO BE THE APPROPRIATE PLACE TO HIDE THE REQUIREMENT. I guess I'd rather see the requirement that only Dollars and Euros are used by my trading partner within an ancillary piece of documentation - or even in a response message saying "I expected only EUR and USD." On the other hand, code value restriction might have found a place in X12 and EDIFACT EDI implementation guidelines because codes were used all over the place to do things names are used for in XML - e.g., to differentiate delivery dates. The only way you could make the DTM segment make sense is if you "restricted" (in the printed guideline) the code value list to the 2 or 3 sensible values out of an EDIFACT codelist containing hundreds. But a Delivery core component gives you only those "Delivery" dates that make sense in that context, e.g., ActualDeliveryDateTime and RequestedDeliveryDateTime. There's certainly no need for code restriction in UBL to differentiate Delivery dates, because there are no codes - only element names. But that's the primary reason folks restricted code lists in EDI; why does it have to be carried over to core components and XML? William J. Kammerer Novannet Columbus, OH 43221-3859 . USA +1 (614) 487-0320
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]