[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
Steve,
I concur on this - put simply W3C schema was *never* designed, intended
nor required to solve these problems.
People *assume* that it is - and continue to look for ways to do this
with it - but it simply is not there.
If you must go back to the W3C official requirements for schema - then
you will see that the people stipulating those have a very different
document-centric, web content view of the world and its use cases.
These people were not and are not - long time users of EDI and eBusiness
transaction systems, nor do they subscribe to the mechanisms and use
cases that are prevalent therein.
This is why back in May 1995 when the X12 report on the needs for the
Future Vision of EDI was developed - "Vision of the Future State: EDI
and ASC X12" that predated the ebXML initiative and XML did not even
exist then - realized that the development of registry services along
with associated integration into content handling services was
essential to next generation eBusiness integration.
The W3C schema and XML architecture specifically excludes dependency on
such registry services. Instead you have the XML parser and the DOM
(!)
The closest you have come to this in UBL is the XPath.xml mechanism. In
CAM we have been actively developing XML structures and mechanisms for
use with ebXML Registry - to allow registry directed information
exchange alignment - abd while the XPath.xml is useful - there is much
more needed - as I believe everyone here is realizing.
I really like this expression of the challenge: "The challenge is to
normalize the semantic dispersion between information points and the
associated processing systems".
See - http://lists.oasis-open.org/archives/cam/200602/msg00000.html
WRT W3C schema - it is just simply not fully equipped to solve this
problem set. What we are looking to do with the CAM work is to develop
XML-enabled tools that do cover off - in a standards based way - these
needs - because people are solving these problems on a daily basis by
writing code - but that is not transferable to someone elses
environment.
To fully enable the ebXML deployment architecture - you need portablity
of these mechanisms across peoples infrastructures - what I like to
call 'integration at point of use'. So you publish UBL schemas - but
you need a standard way of achieving all the above - and frankly W3C
XSD is part of the problem at this point - not the solution!!!
DW
-------- Original Message --------
Subject: RE: [ubl-dev] SBS and Restricted Data Types
From: stephen.green@systml.co.uk
Date: Thu, May 04, 2006 11:40 am
To: ubl-dev@lists.oasis-open.org
Joe,
Hi. Briefly, the use of XSD (or maybe better
still, RelaxNG) is fine for creating a schema
to describe the layout of the subset definition
file (this is getting tricky to say - definitions
of definitions, etc). We can use XSD to adjust the
definition file * layout * such as adding new
attributes to cater for different types of subset.
This is what I meant by 'methodology extension'.
However, I have personally found major weaknesses
in XSD (W3C Schema) which fall short of some of the
requirements of UBL and other folk have identified
such problems too.
Three weaknesses seem to be
1. limits of how derivation works, in particular
2. enumerations cannot be derived
3. elements and attributes are either valid or invalid with no further
distinctions allowed
I think these limitations have forced extra work on the
UBL TC, such as for versioning, customisation, codelists
and subsets.
I'd better not go into detail here (short of advertising UBL courses :-)
but the in-progress customisation methodology, codelist
methodology and just finished subset methodology, together
with improvements in the XML design of the UBL 2 schemas
these things do seem to answer the main aspects of these
problems, even if not perfectly. They required us to go
beyond what W3C Schema allowed and into Schematron, XPaths,
custom XML definitions (such as genericode) and maybe NVDL.
We put out long, in depth enquiries and investigations such
as on XML-dev and the like to ascertain that W3C Schema wasn't
sufficient to do all this with and still had to use the above.
All the best
Steve
Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
> Please see comment regarding the following, marked with [JMC]:
>
>> (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 :-(
>
> [JMC] Comment on both responses above, and speaking only for W3C Schema:
> Given that W3C Schema already has features such as extension and
> redefine that are supported by many tools today, at what point does the
> "methodology extension" referred to above begin to re-invent what W3C
> Schema already allows? There is also the mention of "more granular,
> tighter subsets and a schema extension for such definitions" - knowing
> the issues folks have with W3C Schema, what is so lacking about W3C
> Schema (a ratified standard for 5 years now) that warrants potentially
> reinventing the wheel here? (continued below - breaking for
> readability:)
>
> [JMC] If all one really needs to do is restrict data types using
> constraining facets, and add additional elements not currently
> supported, this can be done with W3C Schema. What am I missing here?
> What is the benefit of using SBS over such an approach? Please educate
> me, as I want to learn.:) (I predict that David Webber will now come in
> again and talk about what is lacking about W3C Schema, and why CAM is
> needed;)
>
> 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 2:20 PM
> To: ubl-dev@lists.oasis-open.org
> 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:CommonBasicComponent
>> s-
>> 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:CommonBasicComponent
>> s-
>> 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/
>>
>
>
>
>
> ---------------------------------------------------------------------
> 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/
>
> ---------------------------------------------------------------------
> 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/
>
>
---------------------------------------------------------------------
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]