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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


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


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 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
> capability 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
>
>>>> "Chiusano Joseph" <chiusano_joseph@bah.com> 05/05/06 15:51:17 >>>
> <Quote>
> If an implementation chooses to constrain a user's use of a vocabulary,
> that is up to the implementation, not to the abstract definitions
> expressed in the vocabulary.
> </Quote>
>
> Well I think it depends on what we mean when we say "implementation" (as
> it's a broad term). I agree 100% (and have always agreed 100%) that the
> UBL schemas should not constrain data types, as this would limit
> interoperability (what if someone needed a string length of 20 instead
> of 10?). They are best kept uncontrained. However, if by
> "implementation" we mean applications (i.e. using application logic to
> check for data type contraints), then in some cases this may be the best
> approach, and in others it may not be (it's a case-by-case basis).
> However, for data-oriented (vs. document-oriented) XML, I do believe
> that there will be many cases in which it is advantageous to check such
> constraints "on-the-wire" using - for example - an XML schema, but
> having the constraints "baked in" to the schema itself. In other cases,
> on-the-wire validation may not be the best approach (for example, for
> throughput considerations), and validation in application logic may be
> best.
>
> Having said that, since the UBL schemas cannot constrain data types (and
> I don't believe that they should), if there were a mechanism within a
> tool/methodology to enable users to constrain data types and validate
> them on-the-wire, I believe it would be very valuable.
>
> FWIW, I'm not seeing the connection (though I understand *what* we are
> trying to connect) between small businesses and lack of data type
> constraints (I say this because the SBS is for small businesses, and it
> doesn't have the ability to constrain data types). I know that
> application logic can check for such things, but I don't see why it
> wouldn't be advantageous for the applications that support small
> business to be able to validate data type constraints on-the-wire (in
> addition to things such as element names, etc.) through XML schema-based
> mechanisms, such as those that SBS currently offers (meaning in addition
> to those capabilities). If ability to check for things such as
> cardinality on-the-wire is there, why not string length? Or number of
> decimal places?
>
> Of all types of businesses, I would think it would be best for small
> businesses to ensure that their data is conformant to requirements as
> early as possible during an exchange (meaning before it "hits" the
> embedded application logic), and in as efficient a manner as possible.
> Relying on application logic to catch such errors when there are
> facilities already available within existing standards (with the caveat
> that I fully realize the challenges associated with XML schema) could -
> I believe - potentially lead to a greater chance of incorrect data
> "slipping in" to a small business. Consider, for example, what would
> happen if a incoming monetary amount did not have the proper number of
> decimals, and the application logic was not able to catch this? Of all
> types of businesses, I would think that a small business would be most
> impacted by such a scenario.
>
> Also, having such capabilities outside of the application logic could -
> I would think - potentially lower implementation costs for vendors, as
> they can take advantage of existing standards rather than "rolling their
> own" logic.
>
> These are just my views - I respect all opinions on this, and none of
> them can be wrong (even though I welcome anyone telling me that mine is
> wrong:).
>
> 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:03 PM
> To: ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] SBS and Restricted Data Types
>
> 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.
>
>> What has happened to the notion of contract-based interoperabilty,
>> where trading partners adhered to a technical contract to the greatest
>> degree feasible and possible? Why leave data type restrictions (such as
>
>> string
>> length) out in the cold? I really don't understand what the issue is
>> here (please note that that is not a criticism of your perspective).
>>
>> So with all due respect, and for what it may be worth, I completely
>> differ with your views on interoperability as expressed below. That is
>> not to say in any way that they are incorrect - I just have a very
>> different perspective on interoperability, and the possibilities that
>> can be realized.
>>
>> Please correct my thinking if needed - I want to be told I am wrong if
>> you or anyone else believes I am.
>
> Who is to say what is "correct" Joe when dealing with perspectives?
>
> For my two cents (Canadian), implementation constraints such as string
> length have no role in XML vocabularies.  XML vocabularies are used to
> express user's information so that users can convey what they need to do
> their business.
>
> If an implementation chooses to constrain a user's use of a vocabulary,
> that is up to the implementation, not to the abstract definitions
> expressed in the vocabulary.
>
> Implementations of standards differentiate themselves by how well they
> work with the standards and which features they offer to their users.
> If in my business I absolutely need to use 100 characters for my
> description, then I'm going to go out there looking for an
> implementation that supports me.  If I can't find one, then I'll have
> other decisions to make, but I would have had that if the "standard"
> arbitrarily restricted me.  But I don't have to make those decisions if
> there are applications that support me.
>
> I don't think implementations should arbitrarily constrain users of XML
> vocabularies ... that is the tail wagging the dog.
>
> If I enter into a trading agreement with a trading partner and we
> mutually agree that our use of UBL will require that a given string be
> constrained to 30 characters, that is a business/technical decision
> between me and my partner, it is not a constraint on the document
> vocabulary, and I'll express that constraint as an assertion that can be
> tested after structural integrity has been tested.
>
> . . . . . . . . . . . . . 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/legalRest
>
>
> ---------------------------------------------------------------------
> 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]