[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
Joe,
Doing this does it for any and every context and role - so if that is
*not* what someone needs - you have a problem. The use of simple
string is obviously a more relaxed constraint that is more likely to
work for any context.
Also - by embedding these things into the schema - you cannot find what
are non-normative extensions and what are part of the standard.
That is why having another layer is crucial - I can look exactly at that
other layer and see immediately what are the deltas... I think that is
where we started from on this yesterday ; -)
DW
-------- Original Message --------
Subject: RE: [ubl-dev] SBS and Restricted Data Types
From: "Chiusano Joseph" <chiusano_joseph@bah.com>
Date: Thu, May 04, 2006 4:03 pm
To: <stephen.green@systml.co.uk>, <ubl-dev@lists.oasis-open.org>
<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/
---------------------------------------------------------------------
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]