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


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


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