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,
jon.bosak@sun.com 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
|