OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cam message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

FYI - discussion item this week on UBL dev vis SBS - and my 'how to' example using jCAM.

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


The example you cite below is very simply implemented using an OASIS CAM
template and the context mechanism that CAM provides.

The weakness in schema is that pretty much everything has to be defined
as optional (min=0 max=1) since there is no direct context mechanism

Conversely CAM has been designed from the start to be eBusiness and CCTS
aware - and now ebBP/BPSS v2.0.3 supports context variables - this can
all be designed out-the-box to work end-to-end - from BPSS definition,
thru CPA agreement to runtime environment in the ebMS and call-out to
CAM processor.

So in CAM you simply group your constraint changes - so you do not have
to hunt them down or look for arcane schema syntax tricks - but instead
toggle them based on a context variable and criteria that you establish
and simple business-analyst friendly XML scripting - and share that
directly with your trading partner.  This gives you a simple and clean
way to implement UBL SBS ( this is the way ebXML context is supposed to
work, no?!).

e.g. as simple as doing this in the BusinessUseContext section of your
CAM template:

  <!--  default structure constraints and cardinality. -->
   <constraint action="makeRepeatable(//SoccerGear)" />
   <constraint action="makeMandatory(//SoccerGear/Items/*)" />
   <constraint action="makeOptional(//Description)" />
   <constraint action="makeMandatory(//Items@CatalogueRef)" />
   <constraint action="makeOptional(//DistributorID)" />
   <constraint action="makeOptional(//CustomerID)" />
   <constraint action="makeOptional(//SoccerGear/DeliveryAddress)" />

 <context condition="//CustomerID = ''">
    <constraint action="makeMandatory(//SoccerGear/DeliveryAddress)" />



I'd be happy to help develop some SBS specific examples if people want
to share some sample XML instances of what they are wanting to achieve.
FWIW - the latest jCAM implementation is just posted to
http://www.jcam.org.uk  and you can find more information from the CAM
TC archives on configuring CAM runtime to match your own local Java
system runtime environment.  CAM now is using the Maven extensible Java
system that allows you to plug in popular marshalling and unmarshalling
and rule engines from the Java community - more details again from the
CAM TC docs area (V1.5 features PPT).

Aka - Here's a quick example of the Maven support including optional use
of a DROOLS external rule engine to the base CAM parsing classes (Yes
you really can just extend CAM by changing this Maven XML!):


Thanks, DW

-------- Original Message --------
Subject: Re: [ubl-dev] SBS and Restricted Data Types
From: stephen.green@systml.co.uk
Date: Wed, May 03, 2006 4:27 am
To: ubl-dev@lists.oasis-open.org

Hi Joe

For example, in the ...-XPath.xml subset definition file you would have

<Element name="Note" type="NoteType" prefix="cbc"

minOccurs="0" maxOccurs="1" text="">

       <Attribute name="languageID" use="optional"

which could be restricted to

<Element name="Note" type="NoteType" prefix="cbc"

minOccurs="1" maxOccurs="1" text="">

       <Attribute name="languageID" use="optional"

making the Note mandatory. This way the SBS mechanism allows
to cardinalities. A reminder that the resulting instances have to be
according to non-subset schemas too (in the SBS methodology) so only
restrictions and not extensions are likely to work.

For facets we decided not to create a mechanism for the committee spec
definitions which would restrict string content - this is to avoid
interoperability problems. If you are in a position to make use of facet
restriction of strings, say with patterns, beyond just restricting
I'd suggest adapting the subset definition to this in a way which agrees
with your business partners but this is at your own discretion and
outside of
scope for the SBS methodology (at present). If you wanted, you could
join the TC to get your method made public to help adoption and
interoperability. In the meantime how about an attribute added here

minOccurs="1" maxOccurs="1" text="" restriction-pattern="...">

I say 'restriction-pattern' because it has to obey XSD rules to still be
valid for XSD - the resulting string, say, has to be schema valid in the
document instance.

This would need an extension to the subset definition schemas (XSD and

How does this answer things? I'd consider whether allowing restrictions
much as this doesn't create problems but it does make sense for
own subsets so maybe UBL's SBSC should consider it as a specified

As for how to create susbets in practical terms, along the SBS lines,
there are a few things to consider
+ how to model the subset (the Small Business SC simply pruned UBL
+ how to generate subset definitions (SBSC used scripting)
+ the need to create one's own uuid for each definition
+ how to publish (SBSC was created to create the definitions as UBL
 specifications and premanently publish them as such in
  http://docs.oasis-open.org/ubl/ for widest use and interoperablility)
+ how to associate the subset definitions (and maybe codelist files,
 with the business process definitions and trading partner agreements
 (the SBS methodology only provides a mechanism for doing this with

A further point is that restrictions of enumeration values are a special
Say you wanted to restrict a code - there is the Codelist Methodology
for that
(in progress for UBL in general but version 0.3 is for UBL 1.0).
If you wanted to restrict an Identifier to add enumerations (as well one
for an implementation, for example with a tax type ID) then I hope the
codelist methodology could be used, perhaps creating one's own
files for the identifiers and codelist association files to relate them
to the
individual instances (document contexts) of the IDs in the documents.

All this relies somewhat on one's being in a position to create one's
subset definitions, codelist genericode files and association files and
associate them with the actual transaction arrangements and publish
The SBS especially provides all this somewhat to aid interoperability as
widely as possible and also to aid adoption where the above said
position is

All the best

Stephen Green

Quoting Chiusano Joseph <chiusano_joseph@bah.com>:

> Please pardon me if this question has been asked before on this list (my
> searches indicated the contrary):
> In terms of the SBS, what is the best way (if any) to restrict data
> types of a UBL schema for an specific implementation? Whether it is a
> 1.0 or 2.0 schema does not matter for purposes of this question (at
> least I don't believe so).
> For example, what if one had a need to define an xsd:minOccurs or
> xsd:maxOccurs facet for an xsd:string data type, for their own
> implementation?
> Thanks,
> Joe
> Joseph Chiusano
> Associate
> Booz Allen Hamilton
> 700 13th St. NW, Suite 1100
> Washington, DC 20005
> O: 202-508-6514
> C: 202-251-0731
> Visit us online@ http://www.boozallen.com
> <blocked::http://www.boozallen.com/>

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/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]