[ubl-ndrsc] Re: [ubl-lcsc] Re: [ubl-lsc] Re: XML Schemas for UBLrelease 0p65

[Lisa Seaburg <xmlgeek@gmi.net>]

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>