Re: [ubl] Definitions of the Name element

[Tim McGrath <tim.mcgrath@documentengineeringservices.com>]

as roberto noted there are different uses for document names and types.

the common names used for documents are not semantically consistent  or 
necessarily meaningful but we have to recognize what they are. one use 
is contextual, where the terms used to name a document are homonyms of 
documents in other contexts.  The Invoice and Freight Invoice and 
Commercial Invoice are examples of this.  in these documents the use of 
the term invoice is historical - the documents could be called something 
else, they are used in a different context, but that is not common 
business practice.  and, as stephen says, they do share some common 
patterns.
in UBL, document name is primarily a facility to provide a synonym or 
common business term that a community of use may use for the document. 
For example, Delivery Note as the common name for a Despatch Advice 
document.

document type is for a more formal definition for flavours of the 
document that share the same patterns. an example is the Self Billed 
Invoice. that is, a document that shares the same structure but is used 
in a specific business process.

we have long debated the idea of a common 'header'in a document type 
(and UN/CEFACT have the SBDH).  in reality, while there may be some 
common patterns in the root elements of a document type, there are not 
as many as these initiatives suggest.  the danger of creating these 
structures is that they start to creep into the area of message handling 
information.  for example, many of the elements stephen suggests 
actually belong in the message envelope not in the document type 
definitions.  i  favour keeping UBL as a business level document 
language and not a message handling standard.

stephen.green@systml.co.uk wrote:
> What is more, it is 'standard' (EU Directives and presumably other
> regional requirements elsewhere) for an Invoice to include an
> Invoice Type as a piece of text or a code. This is the case even
> with a paper document. UBL merely reflects with XML what is defined
> for each document type by the business world(s). Except that
> occasionally the modeling of documents in XML throws up some useful
> patterns which help to make existing business features reusable and
> consistent across document types - as in this case where UBL could
> usefully add the entity of document type to every document without
> straying from the business requirements - call it rationalizing the
> requirements. Adding 'Note' to each document type is another example
> of this recognition of requirements / features common to document
> types in general, as is 'Name' I suppose. In my opinion. It might
> be useful to recognise a generic *abstract* document type (like
> the CC) that is a useful starting point for creating most new
> document types (not something which is represented using XML but
> something more abstract like the CC).
>
> ID 1..1
> OtherID 0..n (abstract of course, not actually called this)
> CopyIndicator 0..1
> UUID 0..1
> IssueDate 1..1
> IssueTime 0..1
> DocumentType 0..1
> DocumentTypeCode 0..1
> DocumentName 0..n (called just 'Name' in some documents)
> Description 0..n
> Note 0..n
> SenderParty 0..n
> ReceiverParty 0..n
> OtherParty  0..n
> Instruction 0..n (abstraction of various entities)
> DocumentLine 0..n
>
> and similarly for document line
>
> I think eDocs does this but I think it goes a bit further than
> I would by representing it more concretely.
>
begin:vcard
fn:Tim McGrath
n:McGrath;Tim
org:Document Engineering Services Ltd.
email;internet:tim.mcgrath@documentengineeringservices.com
title:General Manager
tel;work:+61 438352228
tel;cell:+61 438 352228
url:www.documentengineeringservices.com
version:2.1
end:vcard