[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
Stephen,
Of course - we've know about this philosophical conflict for a while
now.
Jon and I agree to differ on the approach to this. My position is that
ultimately the two paths meet at the top of the pass over the mountain
- they are mutually complimentary - not exclusive.
Basically how do you move for today's world of highly dispersed
semantics to one with high levels of order and alignment?
The current UBL approach is to take a hard line and demand that there is
only one word and it is the word of the standard, and it is enshrined in
the UBL schemas and though shalt not change these. Once everyone is
using this same language - then there is just oneness and information
flows are like trains on rails.
Pragmatically however - unless you have the luxury of building from
scratch - there are always going to be legacy systems out there and
therefore crosswalks and information conversion to be dealt with, along
with local context requirements that somehow have to be aligned with the
main UBL schema. Thus the need for the second layer in addition to the
schema - tools like CAM.
Also - there's that other gnarly and troubling pesky question - how does
versioning and change management work?
Again - taking the W3C namespace approach - where its an all or nothing
technique - means the word of the standard flows slowly and is only
changed when the moon, sun, stars and planets are exactly aligned, and
that does not happen too often. That is how EDI worked, and
eventually everyone realized that was a major impediment to adoption
and favoured the status quo rather than market agility. [Apparently
however this somehow does not effect XML in the same way?!? ; -) ]
Basically EDI attempted to solve this using something called IMPDEF -
where 20 vendors agreed to support this - but only 2 did - so that
changes to specifications could be automatically distributed via
software that controls the mapping rules and structure and content
formatting.
Enter XML and the notion of registry - and being able to collaboratively
share across a community - definitions and the ability to version those
in a systemicatic way (that does not rely on namespace, praise and
thanks!) - but instead is managed through CPA agreements and UID values
that explicitly allow point versioning to the attribute and content
level - not namespace level.
Therefore we have two tides here working - firstly - "the one way is the
true way"- method - and then the pragmatic method - that seeks to
incrementally over the course of time - to align people to the one way
- and provide extension mechanisms that are dynamic and managed in a
systemic and known way - instead of ad hoc just-write-code approaches
that are not re-usable.
Another core concept in play here is one of business re-use and the
ability for the business personal (there's alot more of them than
programmers!) - to be able to manage the information exchange
mechanisms - the notion that if you can write a spreadsheet - you can
manage your software interchanges.
Of course you cannot force people to do anything - so naturally all
three things are in evidence here -
1) The one way - use only the pure UBL schemas and oneness with W3C and
XSD
2) We can fix anything by just writing code - what were your schemas
again?
3) Formal ebusiness collaboration approach - ebXML model - registry and
XML scripting allow dynamic sharing and information alignment based on
formal mechanisms and standards.
Ultimately I believe that fostering diversity is essential - while also
providing the quick on ramp for the 80:20 use case. This applies
whether you are a small business or a mega corporation - you always
have areas of business that are well founded (typically based on
government mandated practice and reporting / or established
marketplaces with little flux) - AND you have areas of emerging
business that change often.
UBL is seeking to be the former - but parts of the use case are the
latter.
The SBS is dead - long-live the new SBS!
At least it all keeps us busy...
DW
-------- Original Message --------
Subject: RE: [ubl-dev] SBS and Restricted Data Types
From: stephen.green@systml.co.uk
Date: Thu, May 04, 2006 5:29 pm
To: ubl-dev@lists.oasis-open.org
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]