Re: [ubl-dev] UBL Schema Customization

Chin Chee-Kai,

Thanks for confirming for me what I suspected was true. 

I did not want to launch prematurely into a "just use CAM" rant - but
really the fact is that CAM is built to allow you to cover off all the 
issues
you raise below - while still maintaining 100% compliance with your
UBL structures and XML instances - that's the piece that really matters-
that the XML on the wire is consistent reliable and verifiable.

Schema is a useful guide - but when it comes to extended context driven
structure manipulations - that is what CAM is designed to do for you -
by augmenting your schema structure definitions.

So - to use CAM for this -  you can go ahead and create a target base
structure layout in the <structure> section of the CAM template (remember
CAM works as WYSIWYG for XML - so layout out what you want to
actually see output).   Then - using the as:choiceID() mechanism label 
one or
more structure varients that you want to optionally have and include them
all into the structure section too.

Now go to the <BusinessContext> section and put in your rules to select
when to choose the appropriate structure format.  You can declare global
variables - eg $pickmyformat - and set values accordingly - if you need to
externally drive the context - or you can use XPath expressions against
the source XML itself to drive the rule validations.

I've attached a classic simple example of using wildly varying address 
formats -
US, US APO and Canada - to show how you can manage structure in this way.

Notice too that you can also use <as:include> statements if you want to 
include in
syntax fragments from external global definition files - handy if you 
are going
to use the same thing repeatedly across all your structures.

The jCAM engine is available from - http://www.jcam.org.uk

and a tutorial on CAM is available from the OASIS TC documents resource 
area.

Enjoy, DW

Chin Chee-Kai wrote:

>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: 
>http://SoftML.Net/
>
>
>
>
>On Mon, 22 Nov 2004, [iso-8859-1] Juha Ik銥alko 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銥alko
>>>TIEKE Tietoyhteiskunnan kehitt鄝iskeskus 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
>>>  http://www.tieke.fi
>>>
>>>
>>>      
>>>
>
>  
>