[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]