Re: [ubl-dev] Storage of UBL documents - ID's

Hi David,

 

I found the emails where we discussed GUIDs / UUIDs for the

UBL documents.

 

https://lists.oasis-open.org/archives/ubl/200602/msg00030.html 

 

I think this was pretty much how it ended up; that the document

level UUID is primarily for storage and therefore there is an implicit

need for the sender and receiver to agree their way to implement

it - or there might be a community to which both sender and

receiver belong which specifies what to use. The sense in which

it is 'universally unique' is defined by the storage / retrieval needs.

If all parties were willing to be use a GUID, then that might be 

what they choose.

 

As my email referenced above shows, it did occur to me that there

were potential pitfalls to avoid, such as assuming that a combination

of document ID (non universally unique, e.g. invoice number) plus

a unique ID for the sending party (plus, perhaps the document date)

might be sufficient. There are other concerns such as the possibility

that there might be different versions of the 'same' document, such 

as copies or erroneous versions and these might need to be 

distinguished too. One aspect of this is that documents have a 'status'

and so there may be various copies of the same document each with

a different status which might need to be stored. It's all pretty much

standard document stuff though which can be agreed between parties,

or within a community of/for parties. A lot might depend on the auditor

requirements or tax authority rules (especially wrt invoices).

Best regards

Steve
---
Stephen D Green

On 15 June 2013 23:05, David Lee <> wrote:

Hello !

I am looking at using a document storage technology to store UBL documents as well as other documents used to create or parse components of UBL documents.   For example I want to store the Order document, as well as say individual Item documents.

Looking at the data model there is frequent use of UUID such as DocumentID .  But these seem to be created by the producer

not the recipient.  Also they don't have any place for a local storage key.   That makes sense as the UBL documents are designed to be the communication between partners not the storage model.

But suppose I wanted to store Order or Catalog documents that I received or generated.

Any suggestions on mapping key fields from these documents to a document management system ?

The systems I am thinking of using would use a "URL" or "path" .. for example Amazon S3 uses a bucket + path to identify a document, but itself is not searchable.    If I were to use such a key-value store for documents which field (if
 any) should I use to create the path ?  the document UUID ?   Also this seems to imply that in such a system I might want (or need) a metadata store as well to map important fields from a document to the actual document store.  This would let one search for
 documents based on things other than the primary key.

If I create a document .. .there is no indication I can find in the spec of the format for document ID's (UUID's),

but the samples look like traditional GUID .. Is there a convention for generating UUID's or is this entirely up to the producer ?

 

Any ideas or descriptions of what was successfully used in practice welcome ! Thanks.

 

 

 

----------------------------------------

David A. Lee



CTO, Nexstra Inc.

http://www.nexstra.com