[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Re: Draft new Additional Document Constraints
Hi Ken, > -----Original Message----- > From: ubl@lists.oasis-open.org [mailto:ubl@lists.oasis-open.org] On Behalf Of > G. Ken Holman > Sent: Monday, 7 January 2013 5:01 p.m. > To: 'Universal Business Language' > Subject: RE: [ubl] Re: Draft new Additional Document Constraints > > While we cannot do anything in time for UBL 2.1, I very much like this idea > and would like to have us consider it for UBL 2.2. Your proposal looks like a good interim solution to move 2.1 forward. > > I wish I had thought of it myself! > > At 2013-01-06 11:18 +1300, JPT wrote: > >Perhaps the answer lies in less detailed property term primary nouns to > >single out different sub-kinds of Text. Type. > > I think you are right. > > >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 ???). > > We needn't qualify all of them, only those that we establish are prose. The > rest are, simply, not prose and just text for whatever reasons. Agree. > >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. > > Agreed, though we needn't introduce a new QDT in the schema, we need only a > new qualification on the text data type as we do today for code lists. We > don't have a qdt: schema type for each of the qualified code lists. And we > can choose to only introduce new qualifications when necessary, where > "necessary" could be limited to, say, conformance criteria. The current code > list qualifications are necessary for validation (which is one of the > conformance criteria). > > Rather than create the unqualified data type "ProseText. Type" we would create > a qualification of "Prose" on "Text. Type" to create the data type "Prose_ > Text. Type. > > No "qdt:" needed in the schema ... consider how we have already done exactly > this with some of the code lists. For example, we introduced the data type > qualifier "Channel" to create the qualified data type "Channel_ Code. Type" > exploiting the existing "Code. Type" without having to create a brand new > "ChannelCode. Type" nor a qdt: data type in the schema. We just qualified an > existing unqualified type. To illustrate: For "Note. Prose_ Text. Type": A "cbc:" named NoteProse would be created, but no new udt: or qdt: required Property Term Qualifier = "Prose" Property Term Possessive Noun = "" Property Term Primary Term = "Note" Data Type Qualifier = "Prose" Data Type = "Prose_ Note .Type" Correct? > >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. > > Yes, later. So for UBL 2.1 my new proposed loosely-defined "used for the > purpose of human language prose" is correct, just not programmatically > checkable. Whereas with your idea implemented as a qualification on the data > type (rather than an entirely new data type), an implementer can > programmatically determine which BBIEs fall under this conformance criterion > and which do not. > > At 2013-01-05 13:46 -0500, I wrote: > > > [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. > > At 2013-01-06 11:18 +1300, JPT wrote: > >A similar approach might be useful for UBL also? > > It absolutely should be considered by the committee. It has zero impact on > the schema-valid checking of the data type, as the "Prose_ Text. Type" is the > equivalent of "Text. Type" from a schema perspective. Just as the "Channel_ > Code. Type" is the equivalent of "Code. Type". In UBL 2.1 the qualifications > characterize the items for value, they don't change the schema checking of the > items. Agree. > But the UBL-Entities-2.x.gc file will correctly identify those DENs that have > a Data Type Qualifier of "Prose". And every parent/child element pairing is > associated with a DEN, so an implementer will know which child elements fall > under this conformance criterion. > > I bet with some thinking we could even build this into the CVA expression so > that our distribution second-pass value validation would validate the xml:lang > criteria for all identified prose elements. Then the implemeter would have > what they need out of the box. That would be great! Thank you Ken. Juerg Tschumperlin Data Management Solutions, Wellington, New Zealand www.d-m-s.co.nz
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]