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

[Chin Chee-Kai <cheekai@softml.net>]

How come it sounded like game-over when it comes to my timezone?? :)

Now that I have the opportunity to re-read more of those questions
and responses transpired, I think Joseph's question about adding
new elements and restrictions such as limiting string lengths to
30 characters (quoting the example used in earlier discussions)
are real-life needs and would help extend the use of UBL if practical
answers could be given.

But, and that's a big-but, that is more like a question on 
customisation of UBL in general rather than how does SBS offer
answers to those questions.  I've not known SBS to target customisation,
whether full-scale customisation or just restrictions, as its 
primary objectives.  Everything about SBS ought to be read as,
"within the confines of using UBL, including documents, 
customisation rules, naming, namespace, ....." and such idea 
has been conveyed in as many ways as Ken & Stephen had tried to 
bring out in their earlier responses.

SBS merely points out a set of elements (again, "within the confines
of UBL ....") that are useful for "Small Business" and subset
(not customise) them in a consistent way with the usage of UBL 
so that implementers has a lower barrier to cross, and where they
do not implement those areas of UBL not specified by SBS, they have
a consistent way of managing and staying within compliance claims.

For Joseph's questions, I'd suggest, if Joseph could do the honor,
to post them to the relevant customisation subcomm of UBL TC.

Before many readers walk away from the thread with the impression 
that SBS is not useful for this, is not enough for that, or not 
suitable for non-SB, etc, I'll just like to add that "Small Business"
is only a convenient way of describing the standardisation 
activities of extracting a useful subset from the larger UBL.
"Small" is also a qualitative than quantitative term here.
Many departments, sections, branches, divisions (semantics of
terms depending on where your locality is), especially cost
centres, behave much like the sort of small businesses that naturally 
come to mind.   For these "small" entities sitting within larger
organisations, if SBS represents a standardised, compliant
subset of UBL that can be used with lower cost of implementation,
more reliable tests (on the basis that much less elements, potential
points of failure exist in the SBS subset), easier training and 
simpler operations, or, as a self-consistent subset that gives rise
to easier pilot trials before moving to the full complex suite of
UBL, the relevant department head, section manager, branch manager, 
or division director might have to ask, "Why not?"



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6820-2979
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Thu, 4 May 2006 stephen.green@systml.co.uk wrote:

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