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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2006-05-03 10:54 +0200, Martin Forsberg wrote:
>Could you give an example of how to use the xpath-files when actually
>validating the document instance?

That is not the role of the XPath files ... they only catalogue how 
much of a normative sacrosanct schema is considered "meaningful" to a 
group of users.

The SBS was created as an implementation guide to rein in 
implementations to a meaningful subset for small business so as not 
to burden a small business user or a vendor with the concern or cost 
of having to support the entire UBL definition.

Without such a formal definition from the TC then all incomplete ad 
hoc implementations would be subset at different informal levels and 
there would be no guarantee of expectation as is now guaranteed for 
both (a) the sender to know that everything he has used from the SBS 
subset is guaranteed to be processed by the SBS recipient, or (b) the 
recipient to know that he doesn't have to support anything outside 
the SBS subset that might come from an SBS sender.

So now users and vendors can claim to support the SBS and there is a 
clear definition by the TC of what is supported.  And the XPath XML 
files make that definition machine processable.  And it is all done 
without a single change to the UBL schemas.

>Is it possible to validate that the
>sender follows the subset and make sure that he sends only what we have
>agreed upon (and no more).

Yes, it is possible, but we don't say how ... we just give you raw 
material with which an application knows the formal definition of the 
catalogue of the subset of constructs.  It is up to the application 
to do any validation however it wishes, using the XPath XML files as 
raw material.

The goal of the SBS was never to generate a schema ... but to 
identify a meaningful subset of full UBL against which 
implementations' and users' expectations can be managed.

The SBS defines a subset without changing the definition of the 
whole.  A shorter fence of expectations for both sender and recipient 
than the high one implied by the specification.  In this way SBS 
doesn't constrain the definition of UBL, it constraints the 
implementation level of applications.

Over time there may be a number of subsets agreed upon between 
trading partners ... none of them will change the formal definition 
of UBL.  Applications must still be prepared to receive and validate 
any instance of UBL as an instance of full UBL using the schema 
constraints published as normative artefacts by the technical committee.

A subset definition constrains how much of the valid UBL instance is
meaningful to the recipient so that the sender can be assured that
everything below the fence is meaningful and the recipient can be
assured that everything above the fence can be ignored.  It does not 
constrain what can or cannot go into a valid UBL instance *from UBL's 
perspective*.

In summary, the SBS constrains implementations by being a formal 
definition of a subset that manages expectations of the sender and 
recipient of an XML instance.  It is not changing the schema 
components of UBL or constraints or anything else about UBL ... it is 
only creating a manageable subset vendors and users can assume 
without going off and creating their own ad hoc subsets.

Now, having said all of that, once an application has validated that 
an XML instance conforms to the constraints of full UBL according to 
the full schemas (while behaviours are not spelled out, an 
application is implicitly not allowed to reject a valid instance of 
UBL constrained by the UBL schemas because there is only the one 
normative definition of what the constraints are), an application 
that *implements* the SBS subset definition can use whatever means it 
wishes in order to implement its logic.

If an application chooses to reject an instance on semantic grounds 
that it only *wants* to implement certain instances, that is a 
business decision and an application decision, it is not a decision 
that impacts on the definition of UBL.

Given the SBS specification is machine processable, you can build 
your own checks and balances ... if you wanted to express those 
constraints using schema syntax you can choose to do so, but there 
won't be a formal expression of those constraints from SBSC because 
the subset is only cataloguing which parts of full UBL are meaningful 
to trading partners.

I hope this helps.

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