At 2005-05-18 07:41 -0400, wrote:
> Ken wrote:
>
> > W3C Schema isn't powerful enough to express what we would
> > like to express.
>
>Has there been a use case and requirements discussion about this? If
>so, could you point me to the relevant documents?
The use case is that the vocabulary we wrote that backstops the XML
instances we deliver to users who do not modify them is supported behind
the curtain by me by using a RELAX-NG schema.
I designed the vocabulary to get the job done ... creating and using an XML
instance ... and thought it best to document the instance by writing the
appropriate schema in a formalism rather than just in prose. I'm not
anticipating any of our users to edit the files, so they won't need the
schema. However, as a committee product, if other groups point to our work
and wanted to know the schema for the files, it would be part of the package.
The requirement is to express a co-occurrence constraint: an attribute or a
particular set of children must exist but not both.
W3C Schema does not support co-occurrence constraints, so I cannot
normatively express my requirement using the semantics of W3C Schema
technology. So, I wrote the schema in RELAX-NG and synthesized a "close as
it can be" mimic in W3C Schema by using a freely available conversion program.
What discussion would there be? I had a requirement and W3C Schema doesn't
fit the bill. There are no relevant documents to which I could point.
> > What is the breadth of scope of the NDR? I understood them
> > to be only for the models of the instances used for
> > transactions. The work we are doing is not expressing
> > constraints on a UBL transaction document, but on support files.
>
>Not sure I agree with your interpretation. For example, I would expect
>that any normative schema, regardless of their intended purpose, must
>conform to those NDR rules that are applicable. It would seem to me
>that if the support files are necessary for the transactions, then they
>must be normative and the NDR applies.
But these schemas are not necessary for the transactions. They are
necessary to express the constraints on an already-created instance (the
XPath instance for SBS) ... systems may choose to use the instance, but
they don't have a purpose to use the schema for the instance.
The schema is also monolithic and doesn't have its own namespace because it
is used in isolation and needn't be incorporated by other schemas. There
are no possible clashes with other schemas.
Therefore, it has nothing to do with the UBL message schemas.
Using this terminology, then, I'll rephrase my question: do NDR rules apply
to project-related schemas that are not part of the UBL message schemas?
> > Should we be handcuffed by W3C Schema everywhere?
>
>There are very good reasons for our longstanding decision on the use of
>XSD.
And I haven't challenged their use for the purposes of interchange of
message schemas as the TC has accepted the limitations of W3C Schema and
the document models of the UBL message schemas do not have requirements
exceeding these limitations.
>I have no problems with also using relaxng or other schema
>languages, but only as alternative expressions. If any aspect of UBL
>requires the use of other than XSD, then we will loose a number of
>potential implementers - including many U.S. Government Agencies as well
>as create an insurmountable roadblock with UN/CEFACT.
"any aspect of UBL"? That's pretty definitive, so I'm going to have to go
and complicate my software to accommodate a limitation of the tools we've
chosen.
If this is the final answer and not "the NDR is designed for and only
applies to UBL message schemas", then I think we are unnecessarily
burdening the behind-the-curtain processes, but I'm part of the team and
I'll accommodate this requirement accordingly.
To discover this was, after all, the objective of my inquiry.
. . . . . . Ken
--
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman mailto:
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
