MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] Draft 2.0 Schemas with Currency Codes edited to unions
Ken,
No worries! The UBL committee is supporting the validation method via
Schematron you are working on. I am trying to make sure that users of UBL
schemas (as you say trading partners) are free to redefine/substitution
group/ or schematron as their hearts or minds direct. I understand the committee
to be going down the path of providing the schematron to users to illustrate how
to validate using that method. I don't know if the group has settled on what
documents, schemas, xml files, are to be normative to UBL and which will be
informative.
The examples I provided in the past showed how to extend or restrict the
schemas. This exercise for me was only to show that the underlying schema didn't
break anything in UBL2.
Let me know if this email didn't clear things up for you.
Marty
At
2005-12-07 10:31 -0500, Burnsmarty@aol.com wrote:
>This is not a
problem. We verified that the use of union of token
>and code list
would not permit automatic validation in parser.
>However, you can see
that the parser does understand the code set
>and note that in XMLSpy
you can pick from the list of codes.
>
>By precluding the use of
substitution groups in the UBL schemas, it
>is not possible to
constrain the acceptable values in the schemas.
>However, use of union
allows others to restrict from this definition
>which was not possible
otherwise.
>
>This is, therefore, what I think is the best
compromise given other
>NDR decisions.
Does this mean there is
no role for the code list value validation
methodology I'm working
on?
If the schemas do not parse against an enumerated list, this
approach
you've implemented appears to require the schemas be modified by
restriction in order to do the value validation. My understanding
was that the schemas used for validation would not be touched (as in
the files were sacrosanct).
Can the restriction be done entirely
from an outside "shell" schema
expression that includes the UBL schema
expression? Is this shell
schema what trading partners would
exchange as part of their
agreement to the coded values they'll
accept?
I looked in your examples directory and I didn't see an example
of
how trading partners would restrict the UBL 2.0 schemas to, say, a
selection of only three currency values. Can you include an example
so that we can see what trading partners would write in order to
restrict a document's use of currency coded values?
I had
anticipated that the changes you were coming up with would
still validate
the "largest set" of coded values, and that
supplemental processes would
be used to validate subsets agreed-upon
by trading partners. The UBL
schemas would be the first pass
required to be passed and rejecting
instances that would never be
acceptable anywhere, and the second pass
would accommodate trading
partner agreements.
If this isn't the
case, then I should stop the supplemental process
to do code list coded
value validation so that there is only be one
way to do it. And that
is fine with me to stop this, as it hasn't
been completely documented ...
just let me know ... there really
shouldn't be two ways to do
this.
Thanks, Marty!
. . . . . . . . Ken
--
Upcoming
XSLT/XSL-FO hands-on courses: Denver,CO March 13-17,2006
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
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]