RE: [ubl-dev] SBS and Restricted Data Types

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

Steve, 

I completely agree - this is one thing we have learned from the CAM work
- that a selection of solutions is always going to be needed - so that
implementers can use what best fits their own deployment environments. 

We're attempting to give people as much flexibility now by using the
Maven tools - but you can never hope to cover every need out there. 

I'm planning to work over the Memorial Day weekend on next draft of CAM
spec updates.  WRT to extended codelists handling - CAM right now has
basic tools implemented for lookups.  We've know that there are
extended use cases out there that we need to review and propose better
solutions for.  Right now we can finesse it via rule extensions
callouts - but it would be better to formalize examples - so these can
be implemented quicker and more consistently by developers. 

Would be good if we could share some actual XML instance UBL examples
and rules to work from with me? 

Thanks, DW 

p.s. Don't hold your breathe on the XSD front - that was one of the
major drivers in starting the CAM work because we realized that the
original W3C Requirements statement for XSD excluded these types of use
cases - so you'd have to get the W3C to first change the requirements...
 


 -------- Original Message --------
Subject: RE: [ubl-dev] SBS and Restricted Data Types
From: stephen.green@systml.co.uk
Date: Wed, May 03, 2006 11:55 am
To: "David RR Webber (XML)" <david@drrw.info>
Cc: Joe Chiusano <chiusano_joseph@bah.com>,
ubl-dev@lists.oasis-open.org, ubl-sbsc@lists.oasis-open.org

re: http://www.oasis-open.org/archives/ubl-dev/200605/msg00010.html

David

Thanks for this. I'll digest it carefully. It exemplifies well my
view that as much as possible implementation has to be left to
the implementers - except where state alignment requires more than
that. So we provided the specification in a neutral way (in SBS's
case using an XML instance rather than prose with a design to
facilitate transformation to machine readable formats as needed,
or to prose if necessary). Then we let folk generate Scehamtron,
CAM or code such as SAX and perl according to their preferences
and needs. This seems the thing to do unless we find the need (for
better state synchronisation and interoperability) to also provide
the Schematron, CAM, etc (as with the provision of the UBP for
ebXML use - or as an example for the equivalent in any other means).

Any thought of a CAM profile specifically for codelists and subsets?
These seem to be, regarding UBL at least, key areas of need and it
might be good to optimise CAM for those two areas with a profile.
The provided examples are great though. Refining these to fit the
exact use cases seems a great idea and perhaps even easier to follow
for implementers than a profile.

Ultimately I stiil have a small hope that XSD might be improved to
cater for 1. derivation of enumerations and 2. a way to say (and maybe
validate/verify) that a schema is a strict subset of another schema
of which it therefore uses the same namespace. Too late for XSD 1.1?
Anyone in earshot on the W3C working group? :-)

All the best

Steve





---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the
UBL OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/