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

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Joe

How about we ask for an appendix to be added to the
SBS for UBL 2 as the start of an evolving datatypes
implementation guide. I can't see how it can just be
dictated what are sensible value limitations. If we
were talking about XHTML which does rely on subsets
we wouldn't really be arguing for limits on say an
<h1>...</h1> content; but software like browsers
probably does have limits, such as how long can an
'onclick' attribute value be before some browsers
can't handle it. But do you or does anyone who writes
XHTML (other than browser developers) know the limit
for a particular type of browser. Maybe there is a
limit dictated somewhere in the XHTML specs but who
knows what, where, whether it is and who cares much?

Obviously there is a legacy problem but there always
is and it is always changing and we usually don't
know 1% of what that problem actually is overall. We
perhaps be realistic in trying to give some sensible
limits out of guesswork - nothing hard and fast, just
so we can imporve on it later without breaking
backwards compatibility. Who would like to start by
providing some general guidelines on what length of
an Identifier datatype content string might cause
enough of a problem to enough software to be published?
Identifiers are surely the key fields to do this with.
They are most likely to have to be stored somewhere in
the legacy systems. Other values could just be stored
as XML perhaps, in some cases, depending on software
design.

All the best

Stephen Green



>>> <stephen.green@systml.co.uk> 05/06/06 14:50 PM >>>
Joe

Hi. I've come round to this - that the expense of creating
individual datatype restrictions for potentially each
trading agreement is burdensome to implementers, even with
the SB providing a restriction of elements to support.

I do apologise that it took such a lot of persuasion on your
part (perhaps the longest thread on ubl-dev) but it now
seems good to me that the UBL 2.0 SBS should include some
default datatype restrictions.

The following would of course be subject to the agreement of
those involved in making the SBS and the UBL TC as a whole.

Would it seem good to you, or to anyone else interested, if
we started with just a few default string lengths like 100
characters for Name datatypes and maybe longer for general
Text datatypes. Perhaps Note elements should have longer
strings. Are there other datatypes to restrict?

I do still have some qualms about this as what do we do
about Amount, Measure, Numeric, Value, Percent, Rate and Quantity
the datatypes based on xsd:decimal? Percent should be easy enough.
So can we have some default, general restrictions for the datatypes
to help many implementers without excluding any. The datatypes are:

Amount  (xsd:decimal)
BinaryObject  (xsd:base64Binary)
Graphic  (xsd:base64Binary)
Picture  (xsd:base64Binary)
Sound  (xsd:base64Binary)
Video  (xsd:base64Binary)
Code  (xsd:normalizedString)
DateTime  (xsd:dateTime)
Date  (xsd:date)
Time  (xsd:time)
Identifier  (xsd:normalizedString)
Indicator  (xsd:boolean, already restricted to 'true'/'false' using pattern)
Measure  (xsd:decimal)
Numeric  (xsd:decimal)
Value  (xsd:decimal)
Percent  (xsd:decimal)
Rate  (xsd:decimal)
Quantity  (xsd:decimal)
Text  (xsd:string)
Name  (xsd:string)

I guess a principle is likely to be that the SBS
should be, for xsd:string say, where length is
concerned, as long as useful because others can
always restrict further but if wanting to restrict
less might have to relinquish SBS compliance. I'm
not quite sure though.

Any tips?

It's great that this thread has all the logical
progress to getting to this kind of conclusion,
though others, perhaps, may still be reaching
other conclusions of course. Thanks Joe, tanks
Ken, David, Chee-Kai, Fulton, Martin and Tony
for this lengthy, thorough consideration.

All the best

Steve





Quoting Chiusano Joseph <chiusano_joseph@bah.com>:

> Agreed - changes to SBS should only happen through the UBL TC, for
> future versions. Good that you submitted comments to the W3C Schema
> comment list as well.
>
> 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 [mailto:stephen_green@bristol-city.gov.uk]
> Sent: Friday, May 05, 2006 11:43 AM
> To: Chiusano Joseph; ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] SBS and Restricted Data Types
>
> Hi Joe
>
> Yes it's just that you gave the impression that someone might * wish *
> to restrict datatypes themselves with the SBS and, to my mind at least,
> implementers are the ones who would want to do that, which therefore
> implies, to me, that implementers would want to be changing the actual
> SBS - which shouldn't happen (except through the proper channels in
> future versions in the UBL TC).
>
> By the way I dropped a line to XML Schema comment list about those
> earlier matters (not officially on anyone's bahalf of course) so we'll
> see...
>
> All the best
>
> Steve
>
>>>> "Chiusano Joseph" <chiusano_joseph@bah.com> 05/05/06 16:36:25 >>>
> <Quote>
> Not quite sure why you give the impression the SBS can be changed by
> implementers. I may have given that impression myself but it isn't so.
> </Quote>
>
> Hi Steve,
>
> Can you please help me understand where I gave such an impression? I
> want to make sure I did not give the impression of the wrong
> impression:). I do understand completely that the SBS can't be changed
> by implementers. Below I was mostly speaking very generally, outside of
> SBS. I did make reference to SBS to convey that SBS does not include the
> capbility of constraining data types (the reason that I started this
> thread), and expanded on that to say that this (lack of ability to
> contrain data types) can potentially negatively impact small businesses.
> I also realize that this may be considered pure, unsupported
> speculation.
>
> 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 [mailto:stephen_green@bristol-city.gov.uk]
> Sent: Friday, May 05, 2006 11:29 AM
> To: ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] SBS and Restricted Data Types
>
> Hi Joe
>
> Not quite sure why you give the impression the SBS can be changed by
> implementers. I may have given that impression myself but it isn't so.
> Maybe it's a misunderstanding of the fact that one can use the
> methodology of the SBS to create other subsets (and I take your point
> that it isn't as suitable for private subsets as I hope it is for more
> public ones). Or there is a caveat (which I've not mentioned before in
> this thread) that one can use the actual SBS as a reference point to
> create quick and ready subsets which aren't much different (say "we'll
> use in this trading agreement or tool UBL 1.0 SBS plus
> allowances/charges at line level in the invoice" or make it more formal
> by using the definitions with extra elements inserted and making it
> clear to all concerned just what has been added or even removed).
> More appropriate perhaps to your situation, one can do the above and
> also use a second specification document of some kind to show datatype
> restrictions where appropriate.
>
> Of course, with the next public review, folk could add comments which
> might result in changes to the SBS (or any other subset owned by the UBL
> TC in the future). That's another matter though.
>
> All the best
>
> Steve
>