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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


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


Hi Stephen,

Could you give an example of how to use the xpath-files when actually
validating the document instance? Is it possible to validate that the
sender follows the subset and make sure that he sends only what we have
agreed upon (and no more). 

Regards
Martin Forsberg

-----Original Message-----
From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] 
Sent: den 3 maj 2006 10:27
To: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] SBS and Restricted Data Types

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