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
