[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Definitions of the Name element
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]