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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


Subject: Re: [ubl-lcsc] Re: [ubl-lsc] Re: XML Schemas for UBL release 0p65


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:
 
  1. 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.
  2. 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.
  3. 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
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 



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


Powered by eList eXpress LLC