Re: [ubl-dev] Creating a new document... where to start?

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

At 2004-06-19 07:36 -0400, Jeffrey P. Silverstone wrote:
>I am interested in the same thing, but, perhaps, for a different reason.
>I am looking at writing a front end for an already existing order and
>distribution system. The existing system, for example, only handles US$, so
>my front end can only take US$. I want a schema to advertise to purchasers
>that I only take US$ and that I can use to validate that orders are ones
>that the existing system can handle. On the other hand, I do not want to
>extend UBL in any way so that every order that I accept will be a valid UBL
>order, but not every UBL order will be acceptable to me.
>
>Perhaps I should publish my restricted schema under my own namespace with no
>reference to the UBL namespace and then accept the UBL namespaces on input
>in addition to my own. Regardless on which namespace, I would have to
>validate it against my own.

I see four options for your situation, including restating yours as the first:

(1) - use a different namespace than UBL for a restrictive schema that 
allows only a subset of values and structures
  - I would not do this myself as established applications looking for 
UBL-qualified names would not recognize your structures as the labels would 
be using your namespace URI

(2) - use the same namespace as UBL for a restrictive schema that redefines 
the UBL schema with additional constraints that do not violate original UBL 
constraints
  - I'm still researching how much effort this would be, as it may require 
a *total* redefinition of an entire construct's definition and not just the 
redefinition of one or two facets of a complex declaration
  - I see this as the spirit of W3C Schema restriction and redefinition, so 
as to describe a new set of constraints for instances that are 
categorically also instances that pass all of the original set of constraints
  - it may be too much bother and may require too much "hands-on" or too 
much tool-based automation to ensure a replication of the original 
constraints (see my opinion below)

(3) - use the same namespace as UBL for a parallel grammar expression using 
ISO/IEC 19757-2 RELAX-NG for structural integrity (e.g. cardinality) so as 
to support a two-pass validation, one against the original constraints in 
W3C Schema for type-checking and one against the grammar expression for 
structure and cardinality
  - this, too, would require synthesizing a copy of all of the constructs 
constraints and would violate my opinion below regarding the use of 
software if the constraints were extensive; but wouldn't be true if the 
constraints were simple; this might be doable entirely using XSLT and an 
abstract expression of new constraints on cardinality
  - a drawback is that it is two steps and if it were necessary to support 
the restrictions in an authoring tool, it would be unlikely that that tool 
would support multiple parallel validation requirements (note, however, 
that ISO/IEC 19757-10 Validation Framework is expressing the choreography 
and orchestration of parallel validation requirements)

(4) - use an assertion schema as standardized by ISO/IEC 19757-3 Schematron 
to assert that desired constraints of content are not violated
  - in your example, this would be easiest: a schema expression with an 
assertion that the currency must be US$ would be very short ... a working 
example is below that checks the example Order XML from UBL for US Dollars, 
plus an edited instance that is in Canadian Dollars ... there is no error 
reported for the USD instance but there is an error reported for the CAD 
instance
  - same drawback as (3) regarding parallel sets of instance constraints to 
be validated to consider validation complete

Summary:

I think for your situation go with ISO/IEC 19757-3 Schematron as you are 
accepting instances and validating them as being USD, you are not setting 
up an editing situation where you are constraining the creation of 
instances to be USD.  You have the luxury of a two-step validation: one 
step to conform to off-the-shelf UBL instances, and a second step to check 
your assertion that the total be in USD.

Opinion:

In my opinion *any* strategy for expressing restrictions that involves the 
use of a software tool is a non-starter and ties people to the use of the 
tool ... people should be able to express constraints easily and legibly 
using simple XML instances or other expressions (it happens RELAX-NG has a 
non-XML isomorphic expression that is easy to read and use).  I do not 
include the use of XSLT above, because if I can use XSLT to synthesize the 
restrictions, then I'm not tied to any tool and can use any conformant 
engine freely available to do what is needed.

Conclusion:

In your situation, you can easily express your restrictions in a simple XML 
instance (shown below) and do not have to use a tool to synthesize any kind 
of parallel schema.

I hope this helps.

................. Ken

p.s. here is a complete ISO/IEC 19757-3 schema for checking that an order's 
line extension amount is in US dollars, used in a session showing the lack 
of errors reported for the USD instance (the usd.txt file has only a text 
declaration) and an error reported for the CAD instance (the usd.txt file 
has an error message):

Z:\data\KenData\dev\ubl\ubldev>type usd.sch
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE schema SYSTEM "schematron1-5.dtd">
<schema xmlns="http://www.ascc.net/xml/schematron";>

<title>Purchase order in US Dollars</title>
<ns uri="urn:oasis:names:tc:ubl:Order:1:0" prefix="po"/>
<ns uri="urn:oasis:names:tc:ubl:CommonBasicComponents:1:0" prefix="cbc"/>

<p>This will assert that the line extension total amount is in USD.</p>

<pattern name="Check for USD">
   <rule context="/po:Order/cbc:LineExtensionTotalAmount">
     <assert test="@amountCurrencyID='USD'"
       >Order must be in US Dollars to be acceptable to this system.</assert>
   </rule>
</pattern>

</schema>

Z:\data\KenData\dev\ubl\ubldev>call xslt usd.sch schematron1-5.xsl usd.xsl

Z:\data\KenData\dev\ubl\ubldev>call xslt UBL-Order-1.0-Office-Example.xml 
usd.xsl usd.txt

Z:\data\KenData\dev\ubl\ubldev>type usd.txt
<?xml version="1.0" encoding="utf-8"?>
Z:\data\KenData\dev\ubl\ubldev>call xslt 
UBL-Order-1.0-Office-Example-CAD.xml usd.xsl usd.txt

Z:\data\KenData\dev\ubl\ubldev>type usd.txt
<?xml version="1.0" encoding="utf-8"?>Order must be in US Dollars to be 
acceptable to this system.


--
Public training 3 days XSLT & 2 days XSL-FO: Phoenix,AZ 2004-08-23
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 Breast Cancer Awareness  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal