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


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]