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


Thanks Joe

Quoting Chiusano Joseph <chiusano_joseph@bah.com>:

> 2 questions also come to mind:
>
> (1) Regarding the approach proposed just below: The XPath.xml subset
> definition files do not specific the data type for an element. Given
> that the set of valid constraining facets for an XSD simple data type
> varies according to the data type (e.g. for a data type of xsd:date, a
> constraining facet of "maxExclusive" is valid, but that same
> constraining facet is not valid for xsd:string), it would therefore not
> be possible to validate that a given constraining facet (what we call a
> "restriction-pattern" below) in an XPath.xml subset definition file is
> valid given the element's data type.

I guess these are just the things we'd need to consider for
a methodology extension to cover implementation-specific,
more granular, tighter subsets and a schema extension for
such definitions.

>
> Therefore, during validation one would need to refer back to the full
> schema for the data type - unless the data type was also included in the
> XPath.xml subset definition file. Is this correct?
>

Yes, one has to provide a developer (or auto-generation tool) with both
subset definition and the parent schemas. My guess is (not having examined
it in detail recently) one has to do this anyway, unless there is reason to
combine all the schema information into the subset definition   :-(

> (2) Wouldn't the restriction-pattern also need to be added to the XPath
> file (the one with the actual XPaths) as well, since we include
> cardinality information in that file?

Thanks for pointing out that these files do have cardinality info; at
first we didn't do this. I might have given a bit of false information
in a previous posting about this (OK, I admit it - I forgot, sorry).
I guess my emails aren't normative, perhaps not even informative in
this case :-)

As above, this kind of granularity was out of scope (probably still is)
for the SBS and its use case for subsets in general. Only implementation
specific subsets are likely, I'd think, to need such detail. If we think
of extending the methodology we could consider these things. Any chance
you could send this and anything like it to the SBSC or UBL TC using the
comments form as this gives us permission to use it in UBL? I think this
is acceptable outside of a review period but there may be a review
coming in a few months time anyway.

We wouldn't, perhaps (a guess) be providing such files with the actual
SBS since it doesn't subset to that degree (deliberately, in view of
its purpose to cater for the widest range of implementations). It seems
best to keep to a max level of detail being cardinality for the SBS. Even
that isn't yet subsetted in the existing SBS owing to its scope.

Thanks again

All the best

Steve

>
> 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
>
> -----Original Message-----
> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
> Sent: Wednesday, May 03, 2006 4:27 AM
> 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]