Re: Draft new Additional Document Constraints

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Based on my analysis of the document models yesterday:

  https://lists.oasis-open.org/archives/ubl/201301/msg00004.html

... I think my proposed new additional document constraints fall short:

At 2012-12-20 12:31 -0500, I wrote:
> During a TC call subsequent to the post below, the wording of the 
> two new additional document constraints was accepted by attendees.
> ...
> ... with editorial changes as:
>
>    [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 have the "languageID"
>           attribute absent.

The issue is with "Text. Type" elements that are not prose and, thus, 
are not human language based.  This came to mind when I saw the 
following DEN in my post yesterday:

  "Item. Keyword. Text" (old): 0..n

This is an example where the following is entirely reasonable, say 
two search criteria for an item that would be suitable for purchase 
as a generic winter decoration or specifically a Christmas decoration:

   <cbc:Keyword>Winter</cbc:Keyword>
   <cbc:Keyword>Christmas</cbc:Keyword>

These data fields are not prose.  They happen to be English, but as 
search criteria, they are data.  But the data type is "Text. Type" 
and the specificity of my proposed wording would indicate that there 
is a violation of an additional document constraint.

Thus, I propose that we consider using the following wording in order 
to address the necessary use of "Text. Type" for repeated data fields 
of a language nature:

   [IND7] Where two or more sibling "Text. Type" elements of the same
          name, used for the purpose of human language prose, 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, used for the purpose of human language prose, exist in
          a document, no two can have the "languageID" attribute
          absent.

The issue is programmability ... inspecting the document model an 
implementer can categorically determine which BBIEs are "Text. 
Type".  But there is no way to categorically determine which BBIEs 
are human language prose.  You and I might know what "human language 
prose" means, but would our typical users?

So, do we leave the new constraints in and leave the interpretation 
up to the implementer (thus preserving the intent of not abusing 
sibling BBIEs for concepts like paragraph), or do we remove the new 
constraints because they aren't programmatically implementable?

Perhaps can we come up with a definitive list of property term 
primary nouns that covers all issues without ambiguity?  I suspect not.

Any thoughts?

. . . . . . . . . . . Ken

--
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/o/
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal