[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Re: Draft new Additional Document Constraints
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]