OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-sbsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


The following is from my recent postings on ubl-dev
related to the possibility much discussed in a thread
responding to and discussing with Joseph Chiusano
called 'RE: [ubl-dev] SBS and Restricted Data Types'
see:
http://lists.oasis-open.org/archives/ubl-dev/200605/maillist.html

In brief, it relates to the lack of provision in the
SBS for limiting datatypes. Implementers are not given
guidance to date on what limits might or should be
applied to datatypes. Some implementations already
include their own 'tight schemas' and specifications
limiting in other ways the datatypes (such as string
length limits, maybe for certain elements).

Any thoughts on whether to do the following for the
UBL 2 SBS

Quoted:

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 SBS 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, thanks
Ken, David, Chee-Kai, Fulton, Martin and Tony
for this lengthy, thorough consideration.

All the best

Steve



Quoting stephen.green@systml.co.uk:

> 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 SBS 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, thanks
> Ken, David, Chee-Kai, Fulton, Martin and Tony
> for this lengthy, thorough consideration.
>
> All the best
>
> Steve
>
>
>
>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]