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: Problem revealed regarding document constraints [IND7] and [IND8]


Fellow UBL TC members,

To address the challenge from Kees (not a formal ticket) regarding writing Schematron for the additional document constraints:

https://docs.oasis-open.org/ubl/csprd02-UBL-2.3/UBL-2.3.html#S-NATURAL-LANGUAGE-TEXT-ELEMENTS
Natural language text elements such as Note and Description appear throughout the UBL document model.
...
UBL enforces this restriction with the following two rules:

[IND7] Where two or more sibling "Text. Type" elements of the same name exist in a document, no two can have the same "languageID" attribute value.

[IND8] Where two or more sibling "Text. Type" elements of the same name exist in a document, no two can omit the "languageID" attribute.

I've written this stylesheet to synthesize what I understand the requirement to be:

https://github.com/oasis-tcs/ubl-2.3-artefacts/blob/feature/Schematron-document-constraints/UBL-DocumentConstraints-2.3.pattern.xsl

And everything worked ... it even found two sample test files in our "xml/" directory that violated the rules, so that's good.

But one of the tests also revealed a problem in that not all "Text. Type" elements are for natural language text, specifically (at least):

>Document Reference. XPath. Text
>http://docs.oasis-open.org/ubl/csprd02-UBL-2.3/mod/summary/reports/All-UBL-2.3-Documents.html#Table-DocumentReference.XPath.Text

And the sample had two XPath address elements, and neither had a languageID attribute ... a clear violation of the wording of the rule as stated currently.

But there are no other CCTS data types we can use for just a generalized string of text:

http://docs.oasis-open.org/ubl/csprd02-UBL-2.3/mod/summary/reports/All-UBL-2.3-Documents.html#UDT

Currently, I'm mechanically distilling all BBIEs of type "Text. Type" ... but because of (at least) cbc:XPath, we need another strategy.

This Schematron is not normative, just a suggestion. We could document the problem and leave it (not any groups I know use this BBIE).

Or we could enumerate all of the BBIE Property Term Primary Nouns for things like Note, Description, Instructions, etc. and perhaps miss some.

Or we could enumerate all of the exceptions and perhaps miss some.

At the least, the wording of the rules need to change a bit.

Does anyone have any suggestions regarding how we proceed?

Thanks for your thoughts!

. . . . . . Ken

--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/o/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |



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