Re: [ubl-dev] UBL Schema Customization

[Chin Chee-Kai <cheekai@softml.net>]

I would think there is.  Basically, the alternative is to
do away with being trapped within the confines of XSD's
extension/restriction mechanism.

So long as you stick to the the idea of customizing using only
XSD extension/restriction mechanisms, you'll have to start off
using a UBL document's schema as 100%, and then extending it with
some components and restricting it to avoid some components and
so on.  You'll end up with something like 
    (((100% + 12%) - 18%) + 1%)
       [1]    [2]    [3]    [4]
[1] - Original UBL document's schema
[2] - Extension to include some of new components
[3] - Restriction to exclude some unwanted components
[4] - Extending again as [3] might have removed too much

when actually what you want is a direct 95% [5].

In the former case (ie, customizing through XSD extension/
restriction), one carries the entire [1], [2], [3], [4]
sets of schemas along all the time, defering the evaluation
of final schema till actual instance validation time.
In the latter case [5], one carries one (final) schema.

In terms of benefits on reusing parsers, interpreters, and
interoperability, it's not clear the former leads in clear
advantage.  One inherits sensitivity to changes in any and
all of [1],[2],[3],[4], and risks having the final form of
[1]+[2]+[3]+[4] being inherently changed when the lower-numbered
schemas get changed.  Furthermore, run-time behaviors 
and semantics implementation of extension/restriction may
not be statically obvious, creating difficulty in knowing
what the final schema actually looks like.

As for [5], the alternative, one reuses from the UBL type
pool the largest semantic type components that match your
new schema's purposes, and include these identified components
as atomic components within your new schema.

I made further elaboration and explored other relating 
aspects of doing the above in:

http://www.itsc.org.sg/synthesis/2004/4_TappingStd.pdf

I'll leave out the details here.  If you're interested to 
read further, please go to the above URL.

Finally, technologies such as XSD schema, extension/restriction,
etc, are supposed to help in what we want to do, not to be
there for us to change to a more complex way of doing
things so we can use the technology.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/




On Mon, 22 Nov 2004, [iso-8859-1] Juha Ikävalko wrote:

>>I use the following (UBL Order-1.0) structure as an example:
>>|Order
>>|----|cac:Party
>>|----|----|cac:Address
>>
>>If we need to add new properties to the Address component, we 
>>create a new FI-AddressType by extending the existing AddressType. 
>>Ok, that's simple. But how should we handle a situation where we
>>require the use of derived type in the Order document? Should we 
>>also create a new FI-PartyType first by disallowing the use of 
>>original AddressType through XSD restriction and then by allowing 
>>the use of FI-AddressType through XSD extension? When it's done, 
>>should we also create a new FI-Order by disallowing the use of 
>>original PartyType through XSD restriction and then by allowing 
>>the use of FI-PartyType through XSD extension?
>>
>>The final structure would be:
>>|FI-Order
>>|----|fi-cac:FI-Party
>>|----|----|fi-cac:FI-Address
>>
>>Thus a more general question is: 
>>Is this kind of recursive process always a necessity when the 
>>use of derived type is required or is there an easier way to reach
>>the same end result?
>>
>>
>>With best regards,
>>
>>Juha Ikävalko
>>TIEKE Tietoyhteiskunnan kehittämiskeskus ry 
>>TIEKE Finnish Information Society Development Centre 
>>Salomonkatu 17 A, 10th floor
>>FI-00100 Helsinki 
>>Tel +358 9 4763 0410, Fax +358 9 4763 0399
>>juha.ikavalko@tieke.fi  http://www.tieke.fi
>>
>>