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

[stephen.green@systml.co.uk]

Can't you guess my answer? Use the same mechanism as SBS but add
your datatype requirements if you must (or better, have a public
LBS like SBS and a more private, less globally scoped tight schema).
In other words, avoid CCTS-compliant customisation and keep to the
UBL schemas as they are with UBL namespaces but restrict in another
layer. You can even use W3C Schema for the tight schemas, just keep
them private (!) and use redefine. It won't, in my opinion be as
versatile as the full mechanism of SBS unless you also keep the same
rules and make implementing software have to accept any UBL document
but throw a non-fatal error for exception handling by a human, say,
if the document validates against the UBL schemas but not your
restricted ('tight') datatype schemas and/or the subset schemas.

At one's own risk of course.

Plus try to get the public subset made a UBL committee spec so others
can benefit, so the widest sets of requirements are tried to be met and
so that you can more easily persuade the supply chain to adopt (as they
may want to use the same subset with any other parties not in the supply
chain).

And if you find it just needs a little more than the SBS why not
just see if we can add to the SBS and call it all BS :-) Or use the SBS.

Thanks

Steve




Quoting Chiusano Joseph <chiusano_joseph@bah.com>:

> Sure, why not:). What do you suggest? (I think I used to know this)
>
> 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: Thursday, May 04, 2006 4:25 PM
> To: Chiusano Joseph
> Cc: ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] SBS and Restricted Data Types
>
> Joe
>
> Do you wish it to be CCTS compliant (ISO 15000-5) ?
>
> All the best
>
> Steve
>
>
> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>
>> <Quote>
>> How would you like to use W3C Scehema to restrict UBL?
>> </Quote>
>>
>> Just like this (using a generic element name):
>>
>> <xsd:element name="SomeElement">
>>    <simpleType name>
>>        <restriction base="string">
>>            <maxLength value="30"/>
>>        </restriction>
>>    </simpleType>
>> </xsd:element>
>>
>> This restricts the unlimited-in-length "xsd:string" to a max of 30
>> characters.
>>
>> :)
>>
>> 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: Thursday, May 04, 2006 3:50 PM
>> To: ubl-dev@lists.oasis-open.org
>> Subject: RE: [ubl-dev] SBS and Restricted Data Types
>>
>> Joe
>>
>> Back again :-) Sorry, lots of emails recently!
>>
>> I think you don't really disagree. Just that you aren't convinced as
>> we are, re:
>>> believe that one should be forced to use Schematron in addition to
>>> W3C
>>
>>> Schema if they don't have to.
>> that "... they DO have to."
>>
>> We have spent years looking at all this from maybe not all but
>> certainly many angles. I expect you could look back over the emails on
>
>> the ubl lists and ubl-dev and xml-dev. We've consulted experts galore,
>
>> spent endless hours and yet we came to the conclusion - which is the
>> bit I think you might actually not so much disagree with as not be
>> convinced of - the conclusion that "they have to":
>> That they have to use Schematron in addition to W3C Schema.
>>
>>> Restricting users from being able to define restrictions for data
>>> types is, I believe, imposing a standard's limits on the whole user
>>> community that might implement it.
>>
>> Not that we are 'restricting users' as you say.
>> Indeed we are presently providing the best advice we can (Jon Bosak is
>
>> hopefully going to start us off with a strawman on this) including
>> details of UBL's extension points for extensions and details on how to
>
>> restrict as cleanly as possible.
>>
>> How would you like to use W3C Scehema to restrict UBL? If you consider
>
>> UBL 1.0 there may be more complexity and limitations than with UBL 2,
>> I think.
>> I did endless prototypes of sets of UBL 1.0 (and UBL 2 prototype) to
>> demonstrate problems and successes with using the W3C Schema
>> derivation mechanisms to extend and restrict types and maybe datatypes
>
>> (not sure what I did about the latter). All of it is available on the
>> public lists and a google on 'oasis ubl prototype'
>> or even 'stephen green ubl datatype' should bring get them. I think
>> they were around Feb last year.
>> Then Marty Burns, Tony Coates and Ken and to some extent myself and
>> particularly Mike Grimley did similar work on extending and
>> restricting codelists, as did a few kind helpers on xml-dev. In the
>> end we came the conclusions that W3C Schema couldn't be used to meet
>> requirements of business relating to restricting and extending
> enumerations.
>> If you can find a way then great. We concluded we would turn to
>> Schematron as many had already advised. So Ken and others worked on a
>> mechanism how to do this.
>>
>> We also concluded that the UBL 1.0 use of a mix of W3C Schema local
>> and global declarations would not allow some types of use of W3C
>> Schema derivation so rather than scrap use of W3C Schema we decided to
>
>> make the next version of UBL (UBL 2) a major version just so that we
>> could make every element and type global just to allow customisers and
>
>> maybe minor version UBL crafters to use W3C Schema derivation. The
>> extra documents and modeling work came later.
>>
>> So there is great scope with UBL 2 to use W3C derivation to extend and
>
>> restrict custom versions of UBL or even to do so without changing the
>> namespace but for that we probably recommend (inexplicitly so far at
>> least) use of our existing subsetting mechanism. That's because there
>> are implications to beware of in using redefine which doesn't change
>> the namespace, whereas Ken's guidelines in previous emails (thanks
>> Ken) adequately explain how to avoid pitfalls if you don't like the
>> idea of departing from the UBL namespace. Plus we are introducing in
>> UBL 2 a way to keep the namespace and yet extend (using planned
>> extension points
>> - again a W3C Schema mechanism - xsd:any).
>>
>> Hope this helps
>>
>> Steve
>>
>>
>>
>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>
>>> Ken,
>>>
>>> Respectfully: It's not that you're not getting your points across -
>>> you are. I just don't agree with them. There's a difference.:) I
>>> don't
>>
>>> believe that one should be forced to use Schematron in addition to
>>> W3C
>>
>>> Schema if they don't have to.
>>>
>>> Having requirements for an initiative is not equivalent to "imposing
>>> two trading partners' limits on the whole user community of UBL.".
>>> Restricting users from being able to define restrictions for data
>>> types is, I believe, imposing a standard's limits on the whole user
>>> community that might implement it.
>>>
>>> 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: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
>>> Sent: Thursday, May 04, 2006 12:37 PM
>>> To: ubl-dev@lists.oasis-open.org
>>> Subject: RE: [ubl-dev] SBS and Restricted Data Types
>>>
>>> At 2006-05-04 12:07 -0400, Chiusano Joseph wrote:
>>>> <Quote>
>>>> At 2006-05-04 11:31 -0400, Chiusano Joseph wrote:
>>>> >The same would apply for data type restrictions - if there were
>>>> >some
>>
>>>> >overriding, unavoidable reason that a trading partner could not
>>>> >honor
>>>
>>>> >a
>>>>
>>>> >length for a description of (say) 30 characters, and they instead
>>>> >sent you 100, then there needs to be requirements for handling this
>
>>>> >situation (e.g. is it ok to truncate the characters beyond the
>>> 30th?).
>>>>
>>>> Then put that in a business rule (i.e. asserted using Schematron),
>>>> don't change the constraints of the expression of the information in
>
>>>> the document vocabulary.
>>>> </Quote>
>>>>
>>>> Recognizing the high value of Schematron and its capabilities beyond
>
>>>> those of W3C Schema, why should someone be forced to used Schematron
>
>>>> in
>>>
>>>> addition to W3C Schema when W3C Schema already has facilities for
>>>> this requirement? (e.g. xsd:minLength, xsd:maxLength, xsd:Length)
>>>>
>>>> I'm very sorry if I am not seeing the intended value.
>>>
>>> I'm very sorry I'm not getting my point across.  I feel I keep
>>> repeating myself and doing so is taking an awful lot of time.
>>>
>>> If you put it in the schema, you are constraining the vocabulary.
>>> The
>>
>>> vocabulary should be considered sacrosanct and untouchable.
>>> Throughout programming it is considered good technical practice to
>>> use
>>
>>> layering (protocols, implementations, constraints, operating system
>>> user interfaces, etc.) where one combines solving different problems
>>> with different appropriate layered solutions rather than creating
>>> (and
>>
>>> having to change) one monolithic solution that impacts on all users.
>>>
>>> Using Schematron one can layer on top of the schemas their own
>>> restrictive rules (business or technical).  If you want to restrict
>>> the length of a description, Joe, that's fine ... go ahead and do it,
>
>>> just don't change the definition of UBL doing so, and the *only*
>>> normative component of UBL is the schema expression.  Those files are
>
>>> really sacrosanct and untouchable.
>>>
>>> And it doesn't make sense to impose one implementation's limits on
>>> the
>>
>>> whole user community of UBL.
>>>
>>> And it doesn't make sense to impose two trading partners' limits on
>>> the whole user community of UBL.
>>>
>>> UBL is defined so that everyone can use it ... why do you insist on
>>> trying to change it?  If you have your own restrictions then
>>> implement
>>
>>> your own restrictions without changing UBL as that changes it for
>>> everyone.
>>>
>>> I have said it many times and you keep asking me why again and again
>>> that I don't want to use W3C Schema facilities or make W3C Schema
>>> changes to the normative expressions , but I feel it is inappropriate
>
>>> to modify the W3C Schema expression since that is normatively
>>> described by the committee and, therefore, should not be touched.
>>>
>>> . . . . . . . . . . . Ken
>>>
>>> --
>>> Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
>>> Also for XSLT/XSL-FO training:    Minneapolis, MN 2006-07-31/08-04
>>> Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25
>>> Also for XSLT/XSL-FO training:    Copenhagen,Denmark 2006-05-08/11
>>> World-wide on-site corporate, govt. & user group XML/XSL training.
>>> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
>>> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
>>> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
>>> Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
>>> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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/
>>
>
>