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