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

D'Oh!  I apologize.  Didn't mean to skirt the rules... I'll submit through

(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

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 

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>

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