[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Definitions of the Name element
Hello my comments below, > 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". It is exactly the name printed on a paper based catalogue. About Collections UBL ITLSC has submitted a request as it seems Collections are effectively groups of Items inside a Catalogue. The textile, fashion, and ceramic sectors are basing their catalogues on Collections. We could say the actual Catalogue is a base Collection, but it will be not sufficient for many industrial sectors. A Catalogue is made by many Collections. We are in late providing full samples for this, hope to do it asap. > > 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. > Here the reason a Bill of Lading can effectively act differently (legally) and called for example "Sea WayBill". > 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. Not common but possible > > TransportationStatus: Name of a status message. > > Waybill: Name of a Waybill. Same for Bill Of Lading. > > 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? The Invoice is identified by a Number (ID) and a date, Vendor data, referenced Orders, and finally the content. There is not name for an invoice, noone will be interested to a "name", people just check the invoice is acceptable by checking the above data. > > 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 > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > Hope this helps Roberto -- UBL ITLSC co-chair Roberto Cisternino UBL Italian Localization Subcommittee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl-itlsc UBL Italia: http://www.ubl-italia.org UBL Writer @ JAVEST: http://www.javest.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]