RE: [ubl-dev] UUID

[stephen.green@systml.co.uk]

Quoting "G. Ken Holman" <gkholman@CraneSoftwrights.com>:

> I'm appreciating this discussion.
>
> At 2006-09-04 02:58 -0600, stephen.green@systml.co.uk wrote:
>> My feeling on this is that
>> 1) as a technical feature a UUID concept suggests uniqueness even
>> between different copies of a document
>> BUT
>> 2) as a business semantics feature it is required that the same UUID
>> be used for separate copies of the same document
>
> What would be the context of using the UUID from outside the document
> for something like a line item?

This would be the main purpose of the UUID - mainly for business
reasons, such as refering to an Order or Order Line in an Invoice.
Certain considerations ignore whther it is a copy (so the UUID has
to be the same regardless) and in other ways it has to known
whether it was a copy (such as whether duplicate payment could occur
or has occurred).


>
>> As such the UUID in UBL is a semantic feature and is there for
>> business and legal purposes in the legal documents such as the Invoice
>
> For what purpose?  And does the purpose change given the information
> item being referenced?

As above, this varies, yes. A UUID for an overall Order document has
a different purpose to a UUID for an InvoiceLine, etc. A UUID for a
Party has a different purpose again. Sometimes the use has legal
implications (an Invoice number has to be unique to a Party, say,
except when a copy of the invoice is concerned, and a company can be
fined if it contravenes best practise on this when Tax is concerned.
A contract reference will be subject to other legalities again as will
a payment for working hours. The audit trail is often the most
important matter and might mean very heavy losses in a court case if
it is broken (such as by duplicate references where there shouldn't be,
according to best practise or law, or differing references where there
shouldn't be, as when a Party is paid under two different IDs).


>
>> However I'm a little concerned that the suggested use for ID/IDREF
>> overlaps a little with the requirement for a technical feature so if
>> there is a temptation to place technical (1) requirements over semantics
>> (2) then this temptation should be resisted and something designed for
>> the technical added instead (e.g. actual XML ID/IDREF).

By this I meant that the technical matter could cause problems for the
business matter and should be secondary, subject to best practise and
audit guidelines, etc. My wording might have suggested that the technical
might override the business/leagl but I don't think that is acceptable.


>
> But the purpose of ID/IDREF is just for referencing
>
> And it is too late now to add anything.
>
> Plus there is a prohibition against attributes in the NDR (though I
> happen to disagree with the prohibition, I'm going with the flow).
>
>> As an example to help demonstrate the importance of preserving the
>> semantic business function consider an invoice number: One wouldn't
>> expect a copy invoice to have a different invoice number to the original.
>
> Fine ... for an invoice number ... but you rightly point out:
>
>> As an example of the separate nature (separate 'layer' nature) of the
>> technical requirements consider that a copy in the case of UBL is
>> different from the original anyway by virtue of its having CopyIndicator
>> set to true. Thus it is tempting to give such a document a different
>> UUID if only the technical matter is considered and if the UUID BBIE
>> is used for that there is obviously a breach of the semantic requirements.
>
> Right ... and I don't mind (though it is a pain) using all new UUID's
> for a copy of a document.
>
> But given such a limited semantic definition of "A computer-generated
> universally unique identifier (UUID) for X" that doesn't appear to
> restrict its use.

One could define it as ISO 115... whatever but the business use doesn't
necessarily require that. The uniqueness is dependant on the context of
use and determined by commonly known best practise for that context. For
example when referencing an invoice it is best practise to be able to
distinugish one invoice from company A from any invoices from companies
B, C, D... depending on the context. This is traditionally by combining
Invoice number with issue date and a unique party ID or the like. A UUID
should be able to perform the same function if the context allows. Other
UUIDs may have to perform other functions. A line UUID may be able to
uniquely ditinguish a line in a uniquely distinguished invoice but the
scope will depend on the use (e.g. marketplace scope, universal scope or
just trading partnership scope may be all that is necessary) but the
fact that the scope of uniqueness is greater than some such requirements
doesn't in many situations cause any problems.


>
> What is the hesitation for using this value as a reference from the
> extension area to the main body of the instance?

None at all unless the technicalities change the purpose and perhaps the
practise away from the business purpose and practise. In such cases XPath
might be better (and I'd guess there will be such cases).


All the best

Steve


>
> . . . . . . Ken
>
>
> --
> UBL/XML/XSLT/XSL-FO training: Vårø, Denmark 2006-10-02/06,11-20/24
> UBL International 2006  2006-11-13/17 http://www.ublconference.com
> World-wide corporate, govt. & user group UBL, XSL, & XML training.
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
> Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org