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.
Bill
Burcham
Sr. Software
Architect, Standards and Applied
Technology
Sterling
Commerce, Inc.
469.524.2164
