[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
Steve,
Sorry for the delayed reply on this - got whisked away Friday on
something unexpected, and now back to e-mail. Thanks for your kind
expression below.
I would be very happy in the future to provide feedback on what I need
to get from UBL in the context of the discussions we have been having on
SBS. Speaking very generally, I plan to always recommend UBL for my
clients wherever appropriate and possible, and to the greatest degree
possible. For my US federal clients, this is 100% in line with OMB
Circular A-119 on the use of Voluntary Consensus Standards (VCSs).
As for the initiative I am currently focused on (a cabinet-level US
federal agency involved in large deployment test for an international
supply chain, as a public/private partnership), it is clear that SBS
will not work for our requirements (though I am sure it will be valuable
for many initiatives). So I will need to think of an alternate approach
to recommend, based on the excellent discussions we have been having
here (for example, CAM is still very much on the table, as are W3C
Schema extensibility techniques, along with other options).
Once we get through the deployment test, I will be in a much better
position to provide the feedback you requested below.
Thanks again,
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 5:29 PM
To: ubl-dev@lists.oasis-open.org
Subject: RE: [ubl-dev] SBS and Restricted Data Types
Joe
Sorry, I didn't know, or I'd forgotten, that you were an early UBLer. We
owe a lot to you then. Thank you.
Back to the thread a bit: Is it an unfair question to ask what you need
to get from using UBL - which particular benefits and aspects of it and
if interoperability, to what degree? Obviously if you are at liberty to
answer this it helps, now that UBL 1.0 actually exists more than as a
concept, to reconsider what, to put it a bit crudely, UBL is good for.
What interoperability can be achieved from it now it is a Standard.
Really I should have dared ask that before presuming to answer any of
your questions, being new to standards work myself. If thinking about
HTML or XHTML it is more obvious: one uses it if possible without change
or, with XHTML, choses voluntarily to use a subset (one has to as far as
I know) but one doesn't create one's own because where would be the
interop. One might have said that about HTML when XHTML came along -
what is the point of using it if fewer browsers support it. Now that is
less of an issue and it didn't stop W3C producing it. But it was
produced as a standard and not as a private change to HTML.
But the example doesn't quite match with UBL does it. There is more
reason to just use a homebrewed 'standard' when just transfering data
between systems since the software is often bespoke anyway or
customisable (it might just be a spreadsheet at either end say).
Why use a standard like UBL then? Does custoisation destroy all the
benefits of maybe what we think are the intended benefits aren't quite
the real benefits real implementations seek.
I guess I'm asking for a much appreciated reality check on our
assumptions.
All the best
Steve
Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
> I'm slipping in here at a random point to express my gratitude to all
> those who have contributed to this (long) thread thus far. Thanks so
> much to Steve, Ken, David, and any others who I might be forgetting.
> It's understandable that folks get very passionate about what they
> have produced (and that's the way it should be!), and it's wonderful
> that they can also see beyond that for those who might have different
needs.
>
> As some of you know, I was one of the early UBLers back in 2001, and I
> am very proud of what we created. I also need to ensure that I balance
> that with the needs of my client, and for any future clients that
> leverage UBL (of which I hope there are many:).
>
> Please keep the thread going if you have something to contribute - I
> just wanted to slip in now to say 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
>
> -----Original Message-----
> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
> Sent: Thursday, May 04, 2006 4:42 PM
> To: Chiusano Joseph
> Cc: ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] SBS and Restricted Data Types
>
> 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/
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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]