All,
I think there are pros and cons to the proposed approach. I have some some
brief analysis and offer the following thoughts for discussion. Some of the
answers can probably be provided through refinements to the method. Others
may be more problematic.
The Good Stuff:
A single description in Schematron tests all instances of type 2 (code
list as attribute) usage.
UBL schemas don't have to accommodate code list
extensibility.
More Problematic:
The schematron tests for attribute name and therefore bypasses
the use of the context of the schema -- therefore it can
ignore the schema's constraints. For example, what if the schema designer
wants to constrain the values in a particular usage but not others.
Approach is namespace insensitive.
How does one detect that an instance file is based on an extended code
list?
How can one tell in the instance file what code lists are being
used?
How does one detect that the correct version of the code list is being
used?
Where is the code list itself?
What does an extension document look like?
What does a restriction document look like?
How is versioning handled?
Still need to develop:
xslt that translates code list in XML to schematron form.
Examples of schematron to handle type 1 (code list as element)
Construction of schematron to handle all validation of ubl instance
documents. How complex will this be? Is there any processing resource demands
imposed by this method.
Marty
In a message dated 8/29/2005 8:26:50 P.M. Eastern Daylight Time,
writes:
Hello
UBL TC,
Attached is a hacked-on version of a preliminary demo of
the
schematron concept we've been considering for published
code
lists. Ken prepared the demo and then I hacked on it a little
to
show an approach that an inexperienced user might take with
it.
The demo consists of two parts: first, a preparation stage where
a
set of schematron assertions is transformed (once) into a set of
.xsl
files, and second, a little batch file that runs those .xsl
files against a
given UBL instance. (The .xsl files could be
generated fresh for each
run, but for performance reasons, I'm
guessing that most users would
generate them once and then
validate against them until some change in the
code list or the
business rules required an update.) In the file
attached, all of
this is assumed to be taking place in a Windows XP
environment; I
plan to transfer this over to linux, but Ken reminded me
that it's
time to share what we've got so far, so here you are. The
XSLT
processor I used is xalan-c, just downloaded off the web
and
installed per instructions. (You have to install xerces
first,
and you have to put both sets of binaries into the XP
PATH
environment variable, but the whole installation took me less
than
half an hour including the downloads, and I have never used
either
package before.)
The initial preparation is done by running
prepxsl.bat; this
takes as input three schematron files
named
currency-valid.sch
currency-allowed.sch
currency-value-valid.sch
and
generates three .xsl files named
currency-valid.xsl
currency-allowed.xsl
currency-value-valid.xsl
When run against a sample instance using the
batch file
testxsl.bat, the three generated .xsl files check the instance
as
follows:
- If the document contains an amountCurrencyID that is
not a
standard currency code, then an error message indicating
this
fact is produced. This is the level of validation
we would get
using XSD. The schematron file containing the
assertion for
this test (currency-valid.sch) was created by
Ken; in the real
thing it would have been generated
automatically from the code
list itself.
- If the
document contains an amountCurrencyID that is a valid
currency
code but represents a currency that is not accepted by
this
branch office (for example), then a different error
message
indicating this fact is produced. For purposes of this
demo, the currencies accepted by the hypothetical branch
office
are CAD, JPY, and USD. The file from which this
.xsl was
generated (currency-allowed.sch) was created by me in
a few
minutes using the first file as a model. I've
never created a
schematron file before, so obviously this
level of adaptation
is not rocket science.
- If the
document contains an amountCurrencyID that is not both
one of
the three accepted currencies and also within the
accepted
range for each currency, then a third kind of error
message is
produced. The file used to create this test
(currency-value-valid.sch) was written by Ken, but I feel
confident that I could adapt it to check different ranges
using
the given file as a model.
Four sample instance
files are included in the attachment. The file
testgood.xml is a
valid UBL invoice. The file testbad1.xml is the
same file, but with
one of the stock currency codes (USD) replaced
by JPY; this is a valid
code, but the amount in the invoice (.50)
is considered out of range for
yen, so it should fail just the
last of the three tests. The file
testbad2.xml is the same as
testbad1, but JPY has been replaced by FJD,
which is a valid
currency code but one that's not accepted by this
installation, so
it should fail both the second and the third tests.
And in the
file testbad3.xml, FJD has been replaced by ZZZ, which should
fail
all three tests. (Obviously this is backward from the way a
good
demo would be constructed, but to make it more sophisticated,
I
would have to trap error codes or look at the error
messages
themselves; maybe next time.)
If you set this up in the
same environment I used to test it, your
session should look something like
this:
1. Create the .xsl files.
C:\test>prepxsl
C:\test>rem Transform the
assertions into XSLT stylesheets
C:\test>xalan
currency-valid.sch schematron1-5.xsl
1>currency-valid.xsl
C:\test>xalan currency-allowed.sch
schematron1-5.xsl 1>currency-allowed.xsl
C:\test>xalan currency-value-valid.sch schematron1-5.xsl
1>currency-value-valid.xsl
2. Check the good sample
instance.
C:\test>testxsl testgood.xml
Check instance for valid codes
<?xml version="1.0"
encoding="UTF-8"?>
Check instance for accepted
currencies
<?xml version="1.0"
encoding="UTF-8"?>
Check instance for value in
range
<?xml version="1.0" encoding="UTF-8"?>
3.
Check the sample instance in which everything is OK except the
amount in yen.
C:\test>testxsl
testbad1.xml
Check instance for valid codes
<?xml version="1.0" encoding="UTF-8"?>
Check instance
for accepted currencies
<?xml version="1.0"
encoding="UTF-8"?>
Check instance for value in
range
<?xml version="1.0" encoding="UTF-8"?>Currency
amount of " .50 " for the currency " JPY " is out of the range of acceptable
values.
4. Check the sample instance containing a valid currency code
that
is not accepted by this office.
C:\test>testxsl testbad2.xml
Check instance for valid
codes
<?xml version="1.0"
encoding="UTF-8"?>
Check instance for accepted
currencies
<?xml version="1.0"
encoding="UTF-8"?>Currency " FJD " is not accepted at this
time.
Check instance for value in range
<?xml version="1.0" encoding="UTF-8"?>Currency amount of " .50 " for the
currency " FJD " is out of the range of acceptable values.
5. Check the
sample instance containing the invalid currency code.
C:\test>testxsl testbad3.xml
Check instance for valid
codes
<?xml version="1.0" encoding="UTF-8"?>Currency
code " ZZZ " is not a valid code.
Check instance for accepted
currencies
<?xml version="1.0"
encoding="UTF-8"?>Currency " ZZZ " is not accepted at this
time.
Check instance for value in range
<?xml version="1.0" encoding="UTF-8"?>Currency amount of " .50 " for the
currency " ZZZ " is out of the range of acceptable values.
(As I said,
a better demo would trap these in the reverse order
and just bail out at
the first error message.)
Clearly a lot more work is going to be needed
to set this up
properly for the UBL 2.0 package, but I'm not seeing
anything yet
that would prevent us from creating a satisfactory
out-of-the-box
experience, even for people like me who have never used
schematron
before.
Jon
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
