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

[stephen.green@systml.co.uk]

Absolutely the way we imagined it would be with all sorts
of subsets. It's a lot of work but see Scandinavian gov
works on this - I think the results though might look very
much like the SBS :-)  !

All the best

Steve


Quoting Chiusano Joseph <chiusano_joseph@bah.com>:

> Yes, thanks Steve. My purposes are not for small businesses (and I don't
> forsee that I would not ever have such a requirement). So I think SBS is
> just not a good fit for my purposes, and probably will never be unless I
> find myself in a small business situation (which I don't anticipate).
>
> Can we perhaps start working on an LBS soon? :)
>
> 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:22 PM
> To: ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] SBS and Restricted Data Types
>
> Remember, Joe, the SBS stands for small business subset and wasn't
> eaxctly designed for those who have power, resources and scope for
> impact to write their own subsets or even find ways to do without them,
> e.g. by customising.
> Just, though, that if you deal with small businesses who wish to use
> software within their means supporting UBL, it might be that they
> themselves would do well to use (and maybe wish to use) the SBS. I'd
> just suggest trying to cater for these by allowing use of the same where
> appropriate. Even governments of nations are using subsets like the SBS
> after all.
>
> All the best
>
> Steve
>
>
> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>
>> Thanks Ken - I think I can clear up one of my points here, based on
>> your point below:
>>
>> <Quote>
>> but I was under the distinct impression you did not understand my
>> different opinion when you were asking me why we didn't do something
>> (add W3C Schema constraints) when all along we've been repeatedly
>> saying we could not change the UBL normative schema expressions.
>> </Quote>
>>
>> I probably should have clarified this, but all along I have been
>> completely aware of the fact that one cannot change the UBL normative
>> schema expressions (even before I started this thread yesterday). What
>
>> I am saying is that if one uses SBS 1.0, they cannot - as part of SBS
>> 1.0
>> - restrict data types. I'm very sure that the SBS will be very
>> valuable for many users and initiatives, but for my purposes (both on
>> the current initiative I am focusing on and most likely on future
>> ones) I *might* (not saying definitely) find SBS 1.0 to be unusable. I
>
>> do understand that one can write Schematron assertions, but on top of
>> the fact that one needs to also write software to leverage SBS 1.0,
>> for my needs one might as well just use the built-in W3C Schema
>> features to perform the restrictions.
>>
>> Additionally, I know that SBS 1.0 does not incorporate the ability to
>> add elements/attributes to the "base" UBL 1.0 schemas - which means
>> that one needs to find another means to handle this aspect, one option
>
>> being to use W3C Schema's features.
>>
>> Again, I'm very sure that the SBS will be very valuable for many users
>
>> and initiatives - I just don't see the value for what I need to
>> currently do, and - very potentially - my future projects that may
>> leverage UBL. Leveraging UBL in general - great. Fantastic. Leverging
>> SBS - not so sure, leaning toward no.
>>
>> 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 3:41 PM
>> To: ubl-dev@lists.oasis-open.org
>> Subject: RE: [ubl-dev] SBS and Restricted Data Types
>>
>> At 2006-05-04 15:01 -0400, Chiusano Joseph wrote:
>>> 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 agree there is a difference in agreement ... and I respect that
>
>> ... but I was under the distinct impression you did not understand my
>> different opinion when you were asking me why we didn't do something
>> (add W3C Schema constraints) when all along we've been repeatedly
>> saying we could not change the UBL normative schema expressions.
>>
>> Had I successfully conveyed that UBL users have no leeway to change
>> the UBL schemas, then I wouldn't have been asked why we couldn't just
>> change the W3C Schema constraints to meet users' needs.
>>
>> At 2006-05-04 15:01 -0400, Chiusano Joseph wrote:
>>> I don't
>>> believe that one should be forced to use Schematron in addition to
>>> W3C Schema if they don't have to.
>>
>> And I don't believe I ever said one is obliged to use Schematron for
>> the layering ... one could equally well use Python/SAX for the
> layering.
>> Anyone can use anything as long as they don't change the base W3C
>> Schema expressions.
>>
>> In fact you could use W3C Schema for the layer if you wished, Joe,
>> provided that you don't change the base W3C Schema expressions,
>> because once you do, you no longer can state that you are conforming
>> to UBL because it would reject an instance that the normative schemas
>> would not reject.  By writing a W3C Schema layer you would be applying
>
>> your application constraints *after* the normative schema confirmed
>> the instance conformed to UBL.
>>
>> At 2006-05-04 12:07 -0400, Chiusano Joseph wrote:
>>> 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)
>>
>> So go ahead and use W3C Schema for your layer on top of UBL ... use
>> anything you want in a layer ... that's the nice thing about layers
>> that they don't change what they are layered on ... I'm of the opinion
>
>> that one just doesn't change the base UBL schemas to incorporate
>> layered constraints because then they are no longer UBL schemas.
>>
>> But if you want to reduce the number of layers to one, you could make
>> a better choice than W3C Schema for that layer since it is not
>> expressive enough for co-occurrence constraints or contextual
> constraints.
>>
>> For code list value validation I happen to have chosen ISO/IEC
>> 19757-3 Schematron because it is an international standard and works
>> well for expressing layered value, co-occurrence and contextual
>> constraints on top of structural constraints.  I wouldn't use it for a
>
>> layer of structural constraints so that would involve yet another
>> layer (for that I would personally use ISO/IEC 19757-2 RELAX-NG).
>>
>> At 2006-05-04 15:01 -0400, Chiusano Joseph wrote:
>>> 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.
>>
>> UBL restricts all users from doing *anything* to the base normative
>> definition ... users can, however, apply any layers of their own
>> requirements on top that they wish in order to make it their own
>> without changing the definition of the UBL document models such that
>> any user can continue to create a conforming UBL instance.
>>
>> . . . . . . . . . . . . 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/
>