RE: [ubl] Re: Draft new Additional Document Constraints

["JPT" <jpt60@d-m-s.co.nz>]

Thank you Ken for describing the conundrum so well.

I agree that finding the definitive list of detailed property term primary
nouns is probably not realistic, or is likely to lead to a volatile list
creating unwelcome versioning overheads.

Perhaps the answer lies in less detailed property term primary nouns to
single out different sub-kinds of Text. Type.

For example, udt:NameType is a specific kind of ccts-cct:TextType, and
different from udt:TextType.
Yet it is the vocabulary designers responsibility to choose the correct
property term primary noun at design time.

That concept of sub-kinds of Text could perhaps be expanded, by adding for
example ProseText. Type and DataText. Type (I'm sure better names can be
identified -  maybe ListItemText. Type ???).

In MXV (UML Model-driven XML Vocabulary design using UBL NDR 2.1), we have
defined similar sub-kinds of Text, but because we did not want to modify the
UBL-UDT schema, we created them as qdt: types.
For example, we have the standard udt:TextType and udt:NameType, and
additionally a custom qdt:NoteTextType, qdt:EmailAddressTextType, etc..,
which are based on udt:TextType.

Keeping that list of qdt: types as short as possible is as important to us
as choosing the right property term primary noun at design time.

The [IND..] rules could then name the sub-kinds of Text. Type to which the
rule applies, or not applies as the case may be.

IMO, the [IND] rules a worthwhile to keep in, even when they are not
programmatically enforceable. By creating a DataText. Type or ListItemText.
Type, they would in fact become enforceable.

A similar approach might be useful for UBL also?

    Juerg Tschumperlin, Data Management Solutions, Wellington, New Zealand
    www.d-m-s.co.nz



> -----Original Message-----
> From: ubl@lists.oasis-open.org [mailto:ubl@lists.oasis-open.org] On Behalf
Of
> G. Ken Holman
> Sent: Sunday, 6 January 2013 7:47 a.m.
> To: Universal Business Language
> Subject: [ubl] Re: Draft new Additional Document Constraints
> 
> 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-help@lists.oasis-open.org