OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl] Discussion of RELAX-NG/W3C Schema normativeness in SBSC work


At 2005-05-18 07:41 -0400, MCRAWFORD@lmi.org 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: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 Breast Cancer Awareness  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]