Hey
Ken, comments on your comments to my comments inline.
Hope
this helps,
Marty
In a message dated 8/30/2005 8:27:23 A.M. Eastern Daylight Time,
gkholman@CraneSoftwrights.com writes:
Because
of my limited availability, I have only a brief response to
some of the
points.
At 2005-08-30 07:53 -0400, Burnsmarty@aol.com wrote:
>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.
Yes, I believe this is a requirement:
The code list mechanism shall
support the ability to begin using a new version of a code list without the
need for upgrading, modifying, or customizing the source schema modules (or
other original referenced material).
It is therefore necessary to
establish a mechanism by which a given code or code list can be extended for
use without having to alter the underlying source material. When such an
extension is made, it is also necessary to be able to determine unambiguously
the nature and source of the modification so that its use can be
validated.
>
>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.
XPath addresses this. Note in
Jon's demonstration how the
"currency-value" rule is declared to be
abstract and is only made
concrete by the use of a non-abstract rule with
a context=
attribute. The demo uses a wildcard
context="*[@amountCurrencyID]"
but could easily just as well use
context="cbc:TotalTaxAmount"
instead for a more focused
context.
Your approach will allow the namespace identifier to be searched but does
not enforce any constraints imposed in the schema itself. I suspect you can't be
faithful to the schema with this method without reconstructing the schema itself
with schematron rules. Otherwise there will need to be specific NDR rules on the
use of code lists that prevent ambiguity when schematron is used as the
validation method.
>Approach is namespace insensitive.
Only the
demonstration is namespace insensitive, one could easily
just as well use
context="cbc:*[@amountCurrencyID]".
Same comment as previous.
>How does one detect that an instance file is based on an
extended code list?
Business rules and the choice to apply a given set
of assertions.
So you are saying there is no way to determine by inspecting the instance
file, what composition rules it is expected to follow?
>How can one tell in the instance file what code lists are
being used?
One could base the context on the presence of the code list
support attributes:
context="*[@amountCurrencyID][@amountCurrencyCodeListVersionID='0.3']"
>How
does one detect that the correct version of the code list is being
used?
Specific values can be checked with the above, or one could
report an
error that a given version isn't being used:
<assert
test="amountCurrencyCodeListVersionID='0.3'">
So what I think you are saying is that the schematron becomes an integral
part of the schema itself and has to be part of the UBL packaging and
versioning. This schematron would refine what the schema says is required.
How do we prevent the schematron from conflicting with the schema since
both check content based on overlapping rules? I think this collision doesn't
occur when schema is used for individual value validation and schematron is used
for validating values based on other values.
>Where is the code list itself?
It is an instance of
the upcoming code list schema and is input to an
automated process to
produce the .sch set of assertions.
Does this mean that a third party needs to construct an XML file for use by
UBL and schemas for all other ebusiness standards? I was trying to devise a
mechanism by which third parties could construct a single reference and it could
be used by all.
>What does an extension document look like?
What is
an "extension document"? In Schematron one merely enumerates
the
desired conditions that must be true or the desired conditions
that must
not be false.
An extension document is a description of changes that a user makes to the
standard schemas that allows for the testing of conformant documents without
having to alter the underlying standard schemas. The extension mechanism would
allow information represented in the schemas to be "extended".
>What does a restriction document look like?
What is
a "restriction document"?
Are you speaking of expressions that extend
or restrict an instance
of the upcoming code list schema? I would
leave such a question to
Tony in regard to his proposed code list instance
expression.
Restrictions are the corrolary to extensions that might permit, for
example, trading partners to agree that, for example, PricingCurrencyCode must
have a value of EUR.
>How is versioning handled?
Versioning of
what?
Versioning of the schematron documents which are required to validate the
instance documents.
>Still need to develop:
>xslt that translates code
list in XML to schematron form.
When we decide what the code list
instance looks like, and then what
a proforma Schematron set of assertions
looks like, the XSLT should
be easily created. It would be a waste
to start writing stylesheets
before knowing the inputs and the
outputs. I don't have any concerns
that if we know the inputs and
the outputs that an XSLT can be
created to use for
illustration.
The question is, how complex will a schematron document be that is faithful
to the schema and completely validates all code lists in UBL usage.
>Examples of schematron to handle type 1 (code list as
element)
My recollection of "type 1" is that being an element is not an
aspect
of its distinction.
However, because everything is XPath,
one can just assert
test=".='CAD'" instead of
test="@amountCurrencyID='CAD'" ... and as I
mentioned earlier the
implementation of Schematron I'm using appears
to be old and deficient and
I'm trying to find an implementation of
ISO Schematron where the tests can
all be based on the current node
and the contexts can be set to either an
element or an attribute.
I will point out here that one distinction of type 1 usage is that the name
of the element is different within the context of the schema. This is slightly
more complex than the type 2 case which uses an attribute that always has the
same name. There is no requirement in UBL, I think, that says that element names
must be globally unique within a namespace.
>Construction of schematron to handle all validation of ubl
instance
>documents.
Schematron is only tasked with value
validation and not structural
validation, though if necessary, Schematron
can be used to constrain
structural validation that may be loosely defined
in other schema expressions.
>How complex will this be? Is there any
processing resource demands
>imposed by this method.
I'm not
sure what you are asking.
We are looking so far at simplified examples. To judge overall complexity
we need a fully done example that validates instance files of the standard UBL
examples such as order.
As Jon illustrated, one only need change the synthesized XSLT
stylesheets whenever the set of assertions changes. If the
assertions do not change, one can use the previously synthesized XSLT
stylesheet.
For as many sets of assertions (and many assertions can
be grouped
into sets) as one has, one runs the synthesized XSLT stylesheet
for
that set. The processing demands can be estimated by the weight
of
running XSLT.
I hope this helps.
. . . . . .
Ken
--
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/o/
Box 266, Kars, Ontario CANADA
K0A-2E0 +1(613)489-0999 (F:-0995)
Male Cancer Awareness
Aug'05 http://www.CraneSoftwrights.com/o/bc
Legal business
disclaimers:
http://www.CraneSoftwrights.com/legal
---------------------------------------------------------------------
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