[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] RE: [xml-dev] Is there a way to reuse and extend an enumeration in XML schema
I suppose every method would have its pros and cons, and some trade-offs to make. Here's an idea, where I put the trade-off more on the side of reusing existing code list schema. The idea here is to recognize that the Free-Iraqi-Dollar (FRQ) example you mentioned earlier is a momentary local validation issue until that new code value is standardized into the standard code list enumeration. The suggestion below should apply to all UBL code list implementations, but I'll just illustrate with CurrencyCodeType and it should be straightforward to generalize. Downside is it isn't compatible with UBL-1.0cd2's existing method of implementing code lists. A little higher requirement is also expected of local systems that want to implement this (but not that much drastically than what they need to deal with anyway). Its feature, I think, is it doesn't use any schema mechanism that has not been thoroughly ploughed through by UBL TC, so it's usability or otherwise should be easy to inspect. ===================================================================== Existing UBL-1.0cd2 Currency Code List Implementation: <xsd:complexType name="CurrencyCodeType"> <xsd:simpleContent> <xsd:extension base="CurrencyCodeContentType"> <xsd:attribute name="codeListID" type="xsd:normalizedString" fixed="ISO 4217 Alpha" use="optional"> <!-- UBLish Extension (BEGIN) --> <xsd:annotation> <xsd:documentation> <ccts:Component> <ccts:ComponentType>Supplementary</ccts:ComponentType> <!-- ... Other ccts:Component nodes ... --> </ccts:Component> </xsd:documentation> </xsd:annotation> <!-- UBLish Extension (END) --> </xsd:attribute> <!-- ... Other xsd:attribute nodes ... --> </xsd:extension> </xsd:simpleContent> </xsd:complexType> +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+ Proposed next Currency Code List Implementation: <xsd:complexType name="CurrencyCodeType"> <xsd:sequence> <!-- Element to contain Main Code Value. ie., code values which would validate instances without error with existing code list values, and validate instances WITH ERROR if the sender sends WRONG code values (eg. gibberish values). This element ensures that intended valid values are received with correct validation, AND unintended invalid values are rejected with correct invalidation. To instantiate a new code value not found in existing code list, sender skips instantiating this and writes "FRQ" in the next element. For receiver, on finding this element's absence, it must proceed to validate a required presence of <CodeValueCarrier> below. Otherwise it is a fault (invalid element with CurrencyCodeType). --> <xsd:element name="CodeValue" type="CurrencyCodeContentType" minOccurs="0" maxOccurs="1" /> <!-- Element to contain Carrier Code Value. ie., code values such as "FRQ" which is "temporarily" recognised by sender and receiver as "correct" value, but which isn't yet updated in "CurrencyCodeContentType"'s enumeration. This element MUST be present if <CodeValue> is absent, and MUST be absent if <CodeValue> is present, otherwise is is a fault (invalid element with CurrencyCodeType). Note that this element's type is xsd:string, which can contain any valid string to be separately and specially processed by application. By having it as xsd:string, the schema layer is safe from rejecting sender's intended values. Sender who knowingly wants to send values not found in existing CurrencyCodeContentType (such as "FRQ"), AND knows that receiver understands this new value would write that value here. Receiver who knowingly wants to receive a value not found in existing CurrencyCodeContentType should expect the value to be stored in this element instead of <CodeValue> element above. This way of using this element ensures that intended "valid" value (not found in existing code list but recognized as correct by sender and receiver) is validated correctly through schema for higher application layer to take exception processing, as opposed to rejecting the entire instance outright. The exception processing is implementation and context dependent, and may be in the form of a separate local text file list of special codes, draft values, etc. Other cases are as follows: Sender wrote gibberish here. Receiver doesn't recognise and even though schema layer passes through ok, the application will properly invalidate against its own local list of values. Sender wrote what it thinks is "correct" special values (not found in existing code list), but sent to wrong receiver who doesn't recognise the value. Again, receiver treats as gibberish and process instance as fault because this stranger receiver who received the instance incorrectly would not have the requisite special value file to check. Sender wrote here a valid value found in existing code list. Receiver processes this value as if the value were a special case and concludes it is an error, which it is since Sender has erraneously serialized the proper code value in incorrect element. --> <xsd:element name="CodeValueCarrier" type="xsd:string" minOccurs="0" maxOccurs="1" /> <xsd:attribute name="codeListID" type="xsd:normalizedString" fixed="ISO 4217 Alpha" use="optional"> <!-- UBLish Extension (BEGIN) --> <xsd:annotation> <xsd:documentation> <ccts:Component> <ccts:ComponentType>Supplementary</ccts:ComponentType> <!-- ... Other ccts:Component nodes ... --> </ccts:Component> </xsd:documentation> </xsd:annotation> <!-- UBLish Extension (END) --> </xsd:attribute> <!-- ... Other xsd:attribute nodes ... --> </xsd:sequence> </xsd:complexType> ===================================================================== Best Regards, Chin Chee-Kai SoftML Tel: +65-6820-2979 Fax: +65-6743-7875 Email: cheekai@SoftML.Net http://SoftML.Net/ On Fri, 11 Mar 2005, Marty Burns wrote: >>Henry, >> >>Thanks for your interesting post. I am the editor of the UBL code list >>specification and I think your solution may help us trade off some >>difficulties we have with our present solution. >> >>...
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]