[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] [ubl-lcsc] Re: [ubl-lsc] Re: XML Schemas for UBL release0p65
In OrderHeaderType,
OtherDateTime and OtherReferenceId seem
fishy since their multiplicity is 0..*, yet they carry no description
information. So I could have five OtherDateTimes... and how would an
applicaiton know what each meant, or which one was which? Same for
OtherReferenceId. Recommendation: if what
is wanted is the ability to attach some number [0..*] of DateTimes or
ReferenceId's to an OrderHeader, where the meaning of those is
situation-specific and not specified by UBL then each should carry some markup
that allows the application specifying the value to identify that value.
One way to do this would be to create e.g. in the case of OtherDateTime, a new
type called "ExternalDateTime". The content model for that type would
include a DateTime and an element (probably an Identifier) to specify the
meaning of that date time. So an instance that required attached
DateTimes with externally-ascribed meaning might look
like:
...
<OtherDateTimes>
<ExternalDateTime>
<ExternalId>The Date On Which It First Occurred To Me That
UBL Had Some Great Examples Of The Need For What Costello Calls Open
Content<ExternalId>
<DateTime>8-28-2002:9:41GMT+5<DateTime>
<ExternalDateTime>
If identifying external keys is useful, it seems perhaps even more useful to define internal keys. Is it the case the cct:Identifier is always sufficient to define the identifying properties of an object class, or will it sometimes be the case that compound keys will be necessary? (a compound key consists of two or more properties, which when taken together constitute a unique identifier for an object/entity) Recommendation: I suggest that the model adopt a practice of denoting in some consistent way identifying (or in XML terms, "key") properties. I don't think this is as simple as noting that a property of (CCT) type cct:Identifier is always the identifying key for the object class that contains it. I don't think so, since some object classes have more than one property of type Identifier.
|
Bill
Burcham |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC