[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
Don't worry, I already collected the comments and started a whole new comment sheet. I would like to think I am on top of things........ Lisa ----- Original Message ----- From: "Burcham, Bill" <Bill_Burcham@stercomm.com> Cc: <ubl-lcsc@lists.oasis-open.org>; <ubl-ndrsc@lists.oasis-open.org> Sent: Wednesday, August 28, 2002 7:39 PM Subject: RE: [ubl-lcsc] Re: [ubl-lsc] Re: XML Schemas for UBL release 0p65 > D'Oh! I apologize. Didn't mean to skirt the rules... I'll submit through > channels... > > (venerable indeed!) > > -----Original Message----- > From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] > Sent: Wednesday, August 28, 2002 7:33 PM > To: Burcham, Bill > Cc: 'ubl-lcsc@lists.oasis-open.org'; 'ubl-ndrsc@lists.oasis-open.org' > 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: > > > 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. > > > > <cid:597202714@28082002-32d8> > > > > Bill Burcham > > Sr. Software Architect, Standards and Applied Technology > > Sterling Commerce <http://www.stercomm.com/> , Inc. > > 469.524. 2164 > > bill_burcham@stercomm.com <mailto:bill_burcham@stercomm.com> > > > > > > > > > > ------------------------------------------------------------------------ > > > > <cid:part2.01060002.08000307@netscape.com> > > > > -- > regards > tim mcgrath > fremantle western australia 6160 > phone: +618 93352228 fax: +618 93352142 > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC