Definitions of the Name element

[jon.bosak@sun.com]

For background, see

   http://lists.oasis-open.org/archives/ubl/200711/msg00025.html

Summary: The JPLSC raised questions regarding the definition of
"Name" in the Catalogue document.  The current definition of
Catalogue. Name is:

-   A name given to a catalogue.

Tim explained this as follows:

   Catalogue may be referred to by a name such as "winter 2005
   collection".  This may be the way business users identify the
   Catalogue (rather than the ID).  Maybe we could improve the
   definition of "Name" to say "text [that] identifes the
   Catalogue to business users".

To which Saito-san responded:

   YS: I propose the improving definituin of "Name" according to
   your comments.  The definition of "Name" could improve to say
   "A name given to a catalogue.  The name is a text [that]
   identifies the Catalogue to business users. "

With due respect to Saito-san and the other members of the JPLSC,
I must observe that the revised definition adds nothing to the
original one, because the name of something is *always* text that
identifies that thing to its users.  I would suggest that the
perceived clarification here came from Tim's example rather than
from the revised definition.

As in the case of the Description element, a look across the
collection reveals a lot of apparently meaningless variation in
the definition of Name.  Here are the 10 UBL 2.0 documents that
contain a Name element together with the definition of that
element as currently given in each (the definitions have been
extracted from the xsd files to save time):

   BillOfLading: The business name given to the document type.

   Catalogue: A name given to a catalogue.

   CatalogueDeletion: A name given to a Catalogue Deletion.

   CatalogueItemSpecificationUpdate: A name given to the Catalogue
      Revision.

   CataloguePricingUpdate: A name given to the Catalogue Revision.

   CatalogueRequest: A name given to the Catalogue Request.

   ForwardingInstructions: Name of a Forwarding Instructions.

   PackingList: Name of a Packing List.

   TransportationStatus: Name of a status message.

   Waybill: Name of a Waybill.

I see two problems with this situation.

1. The definitions vary without reason.  For purposes of the
   Update Package, I suggest the following:

-   The name given to a particular instance of the document type.

   As I noted in connection with the Description element in
   another post, the CatalogueItemSpecificationUpdate and
   CataloguePricingUpdate may be special cases; but I'm having
   trouble imagining a text occupying the Name field in these
   documents that isn't covered by the suggested uniform
   definition for the others.  If the Name given to these
   documents is really a place to put text that labels a (reason
   for?) a change, I have to wonder whether that information
   wouldn't better be given in a Note, but in any event, if a
   uniform definition like the one suggested is not appropriate
   for CatalogueItemSpecificationUpdate and
   CataloguePricingUpdate, then the genuinely different function
   of Names in these two cases should be described better than in
   their current definitions.

2. It's not clear to me why some documents have a Name element and
   some don't.  From Tim's example, it's apparent that Catalogue
   is a special case; we often refer to something like "Winter
   2008 Collection" because a catalogue instance is felt to have a
   shared persistent identity, but that's not what we're doing in
   giving an ad hoc name like "Packing list for that stuff that
   Remix Corp. backordered" to a Packing List.  I can see a good
   reason for giving all the document types listed an optional
   Name; what I'm not understanding is why that same reason
   wouldn't apply to the other UBL 2.0 document types.  Why don't
   they all have Name elements?  Why would a Packing List have a
   Name and not an Invoice?

   If, as I suspect, this is just an oversight, then the addition
   of an optional Name element to the document types that
   currently lack one should be logged on the issues list for
   2.1.  If this is not an oversight, then we should clarify the
   reason that some doctypes can have a Name and others can't.

Jon