OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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.

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.

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.

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.

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.

Well done, Juerg ... thank you. This is on my list for UBL 2.2 to present to the committee.

. . . . . . . . . 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]