RE: [ubl-dev] Customising and versioning

["David RR Webber \(XML\)" <david@drrw.info>]

Steve, 
  
Yes it does bring up the broader issue of does UBL even need to get into
this level of implementation details? 
  
Since XSD just provides the structure mapping layout of possible
structure elements and content model - its up to implementers to deploy
agreed to solutions around that. 
  
If you go with the CPA / BPSS approach - the CPA will point to document
exchanges in the context of the business process steps that partners
have agreed to - and then supporting the UBL XSD layouts are documents
that describe the actual payload exchanges.   
  
This can vary from the non-runtime approach such as Excel or Word docs
with manual descriptions - thru to tools like CAM that provide
templates of actual structure mappings with rules and runtime
validations between partners that the CPA / BPSS can pass context
settings to.  Today also there's a lot of Java code out there doing
payload marshalling and unmarshalling based on XSD - the "traditional"
approach of handcoding rules and structures. 
  
This would allow UBL to focus on simple XSDs - no complex featuritus -
and then offer a selection of non-normative approaches for implementers
as above.
 
DW
 -------- Original Message --------
Subject: RE: [ubl-dev] Customising and versioning
From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
Date: Mon, September 11, 2006 9:19 am
To: <ubl-dev@lists.oasis-open.org>

Excellent. 

I guess UBL would have to be quite brave to implement such a mechanism
though.

All the best

Steve


>>> "David RR Webber (XML)" <david@drrw.info> 11/09/06 14:14:07 >>>
Stephen,

Should be very straightforward in CAM - since is operates on the
resulting wellformed XMl instances - you merely provide the deltas of
the structure elements as choices and use the "when" switch
contextually to select the tree structure you want - including and
excluding elements / attributes as needed.

Plus - in the latest release of CAM we've implemented an unordered
mechanism - that allows you to be more "fuzzy" about the structure too
- giving you the ability to have fault tolerant validation when your
trading partner has done some extensions that are valid but perhaps you
did not have that pre-configured on your side.

DW




-------- Original Message --------
Subject: RE: [ubl-dev] Customising and versioning
From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
Date: Mon, September 11, 2006 8:45 am
To: <ubl-dev@lists.oasis-open.org>

How does this sound as a potential mechanism for use
of W3C XML Schema for minor versioning? I've never
heard it being used but it just seems to be the natural
consequence of W3C XML Schema derivation mechanisms.
1.
Use xsd:redefine for types (the namespace staying the
same by virtue of absence of minor version identifier)
then
2. 
Base minor version elements on these redefined types
but base them too, using xsd:substitutionGroup, on
the original major version elements; however, due to
there now being a second element with the same name,
use a more specific namespace for the element which
includes an identifier for the minor version.

This gives the following advantages: 
1. use of xsd:redefine allows extensions and perhaps restrictions
of the types without a change of namespace but with perhaps
(please correct me if I'm wrong) less ambiguity than with
xsd:substitutionGroups 
2. use of xsd:substitutionGroups and elements with changed
namespaces reflecting the minor version allows further use of
xsd:susbtitutionGroups by external customizers who use their
own namespaces for further extensions and perhaps restrictions

I've not tested this more than provisionally but it seemed to work
sufficiently, despite being a bit verbose.

There hasn't been a decision by UBL to use redefine for minor
versions and it might be that UBL 2 minor versions just redeclare
every element and type, making the above more academic for UBL
but maybe this is a worthy design pattern for general use with
all-global W3C XML Schema schema sets.

One for DW: how would this work with CAM?

All the best

Stephen Green



---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org 


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org