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