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

["Scott Wiseman" <scott@intercore.net>]

I think you should publish your restricted schema under your own
namespace. This should help.


-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Monday, June 21, 2004 6:57 AM
To: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] Creating a new document... where to start?

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
Computer Los Angeles:		http://www.Computer-Los-Angeles.com
Network consultant Los Angeles http://www.avidware.net
http://www.intercore.net 
Used cisco equipment:		http://www.cisco-equipment.com