[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.

 

DW

-------- Original Message --------
Subject: RE:
[ubl-dev] SBS and Restricted Data Types
From: "David RR Webber
(XML)" <>
Date: Wed, May 03, 2006 11:00
am
To: , Joe Chiusano
<>
Cc:


Stephen, 

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
available.

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:

<BusinessUseContext>
<Rules>
 <default>
 
<context>
  <!--  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>
 </default>

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

 </context>

</Rules>
</BusinessUseContext>

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!):

<container>
 
<component-implementation  
 
class='uk.org.jcam.processor.dataObjects.Template'/>  

<component-implementation  
 
class='uk.org.jcam.processor.dataObjects.DataFile'/>  

<component-implementation  
 
class='uk.org.jcam.processor.validator.DefaultValidator'/>  

<component-implementation  
 
class='uk.org.jcam.processor.trimmer.DefaultTrimmer'/>  

<component-implementation  
 
class='uk.org.jcam.processor.adorner.DefaultAdorner'/>  

<component-implementation  
 
class='uk.org.jcam.drools.DroolsDataValidator'/>  

</container>  

Thanks, DW 

--------
Original Message --------
Subject: Re: [ubl-dev] SBS and Restricted
Data Types
From: 
Date: Wed, May 03,
2006 4:27 am
To: 

Hi
Joe

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

<Element name="Note" type="NoteType"
prefix="cbc"
uri="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0"

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

     
 <Attribute name="languageID"
use="optional"
type="xsd:language"/>
   
</Element>

which could be restricted to

<Element
name="Note" type="NoteType"
prefix="cbc"
uri="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0"

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

     
 <Attribute name="languageID"
use="optional"
type="xsd:language"/>
   
</Element>

making the Note mandatory. This way the SBS
mechanism allows
restrictions
to cardinalities. A reminder that
the resulting instances have to be
valid
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

cardinality,
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
perhaps
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
RNG).

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

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
schemas)
+ 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
committee
 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,
etc)
 with the
business process definitions and trading partner
agreements
 (the SBS methodology only provides a mechanism for
doing this with
ebXML)

A further point is that restrictions
of enumeration values are a special
case.
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
might
for an implementation, for example with a tax type ID)
then I hope the
same
codelist methodology could be used, perhaps
creating one's own
genericode
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
own
subset definitions, codelist genericode files and
association files and
to
associate them with the actual
transaction arrangements and publish
them.
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
limited.

All the best

Stephen
Green

Quoting Chiusano Joseph
<>:

> 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]
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/