OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi David,
I found the emails where we discussed GUIDs / UUIDs for the
UBL documents.
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

Stephen D Green

On 15 June 2013 23:05, David Lee <dlee@nexstra.com> 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]