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

[stephen.green@systml.co.uk]

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/
>
>