ubl-ndrsc — archive

[Tim McGrath]

we are now passed the time for internal debate on these items, even such venerable comments as yours :-) the way to submit feedback is via the comment form included in the distribution package and sent to our technical editor (Lisa).  we dont want this to become an 'on air ' debate over each item. also, please reference the UBL ID so we can be clear which item you are referring to (for example, my schema has neither OtherDateTime nor OtherReferenceId) Burcham, Bill wrote: 40AC2C8FB855D411AE0200D0B7458B2B07345570@scidalmsg01.csg.stercomm.com > Here's my feedback on the schemas: 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>   ... <OtherDateTimes> Where the type of ExternalId is cct:Identifier perhaps, and the type associated with OtherDateTimes allows for one or more ExternalDateTimes. Some of the object classes in our model contain external keys .  An external key is used by external systems to identify records (in the system).  Examples of external keys are LineItemType.SellerId and OrderHeaderType. BuyerId , SellerId .  It would be useful to me as a reader of the model, if external identifiers were explicitly denoted as such.  Recommendation: in the model documentation, adopt a practice of identifying (in some consistent way), external identifiers. 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. B ill Burcham Sr. Software Architect,  Standards and Applied Technology Sterling Commerce , Inc. 469. 524 . 2164 bill_burcham@stercomm.com -- regards tim mcgrath fremantle western australia 6160 phone: +618 93352228 fax: +618 93352142