Re: [ubl] Problem revealed regarding document constraints [IND7] and [IND8]

[Kenneth Bengtsson <kbengtsson@efact.pe>]

Well done, Ken!

I recall that we had lengthy discussions about it last year when we introduced the ReferencedDocumentInternalAddress. Our conclusion at the time was that the cardinality of the XPath should have been 0..1, and that IND7 and IND8 would, in practice, never be broken because multiple XPath elements within a single DocumentReference would by nature be ambiguous and would therefore violate the definition of the XPath element ("An unambiguous location..").

So it is curious that you have found a sample with two XPath elements. Does this sample use "dummy" values just to demonstrate the XML structure or does it contain meaningful values? If it is just a dummy sample then I think we should stick with our current conclusion and simply change the sample to contain only one XPath. However, if it contains meaningful data from which we can derive a real use case for multiple XPaths then yes, we need to review the NDRs.

/Kenneth


ïOn 7/8/20, 10:33 PM, "ubl@lists.oasis-open.org on behalf of G. Ken Holman" <ubl@lists.oasis-open.org on behalf of gkholman@CraneSoftwrights.com> wrote:

    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 |


    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that 
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php