RE: [legalxml-courtfiling] Document identifiers

[Shane.Durham@lexisnexis.com]

>> 2.  Require that either (a) the DocumentID values associated with the Document and Attachment elements in the Blue message structures be equal to the identifier used by the profile to identify the "attached document", or (b) the profile provide for a mechanism to translate IDs used inside the Blue message body into the identifiers it uses to identify "attached documents". 

 

For the systems we are developing for LexisNexis's FileAndServe integrations, we choose (b).

 

In the XML, each of our documents *may* express these functional properties, such as:

 

- documentIds (sender's and/or recipient's value, where necessary)

- documents' relationship to the filing and/or other documents (ie leadDocument vs. supportingDocument)

- documentType (code/description pair representing the functional type of document)

- documentMimeType (standard mime-type expressing the technical format of the document)

- document size expressing the byte count of the document

- document page count expressing the page count of the document

- documentTitle, etc , etc.

 

Finally, we have:

- document URI

If the document is to be retrieved from another system, we use a standard URI such as:

http://yaddayadda?docArgs

 

If the document is to be retrieved from a local system, we would use UNC, such as:

\\localFileSystem\document.pdf

If the document is to be retrieved from a WebService's 'Dime' list, we devised this URI-consistent syntax:

dimeAttachment://dimeAttachmentId

 

Now, before you slam me with 'Hey, that's not official!'  - it is syntactically correct; it just isn't a nationally recognized URI prefix. 

It's kosher - just not internationally-recognized kosher.  The same might be said of other URI prefixes we use in day-to-day life, such as those used by 'Real' and other web-widgets.

 

Though this is not entirely relevant, we also devised a URI to represent a document which is carried directly within our private filing objects.

LNAttachment://AttachmentId  (though, we would *not* exchange such a URI with an external system)

The point here is that LexisNexis has had good success using 'URI' syntax to represent the location of our our binary documents, regardless of whether they are part of a dime collection, or local filesystem, or external system, or even part of a private array of objects.  And the URIs often have nothing to do with the functional property of documentId.

 

Summary:

A document's binary content can be directly represented by embedded base-xx mime data, or it can be represented by a URI. And, both of these approaches can be (should be) entirely independent of the document Id(s).

 

With this approach, we need only devise URI syntax that is appropriate for each of our implementation profiles.

 

- Shane Durham

LexisNexis

 

 

---

From: Scott Came [mailto:scott@justiceintegration.com]
Sent: Monday, May 30, 2005 2:37 PM
To: legalxml-courtfiling@lists.oasis-open.org
Subject: [legalxml-courtfiling] Document identifiers

In the current Review Filing and Review Docketing message structures 
(and their respective callback messages), the structure includes a 
DocumentID.

As it currently stands, the definition of this element is 
very likely too vague for our purposes...the domain modeling workgroup will fix 
that later this week.  (We will likely wind up mapping it to the same GJXDM 
element, but we will have a Blue specific definition to which the element's 
usage in our spec is explicitly tied.)

Anyway, in considering the usage 
of this element in our context, I was wondering about associating document 
information in the main Blue message body with actual documents (either XML text 
documents, or streams of binary octets) that are "attached to" the main message 
body, in a way specific to each messaging profile.  (For instance, in the 
web services profile, this will likely be accomplished using SOAP with 
attachments and the WS-I Attachments Profile.)

I think we want to provide 
a mechanism that allows an implementer to make this association without actually 
reading the contents of the "attached" documents.

In the web services 
messaging profile, if it leverages the WS-I AP (which is based on MIME), each 
"attached" document in the stream will be preceded by a set of MIME 
headers.  One of these headers is a Content-Id header, which contains a 
unique value associated with that document.  This header's value gives us a 
way to refer unambiguously to that "attachment" (whether it's the lead document 
or an "attachment" in the business sense) from within the message 
body.

Note that in general it is not safe to rely on the order in which 
MIME attachments appear in the message stream, as a way to identify them.  
For instance, it is dangerous to assume that the <Document> element in the 
main Blue message body is associated with the first MIME attachment (assuming 
there is more than one attachment.)  It would be much safer to make an 
explicit link.  Many web services APIs do not allow attachments to be added 
to a SOAP message in any particular order.

I think we should consider the 
following:

1.  Introduce a non-functional requirement that 
encapsulates the idea of "attached documents" that are separate from the main 
Blue message body.  Include in this requirement that profiles must uniquely 
identify "attached documents" (which includes "the" document (what we used to 
call the lead document), plus any attachments in the business sense); the 
identifier must be equivalent to XML Schema's string type (which allows it to be 
used as a GJXDM ID).

2.  Require that either (a) the DocumentID 
values associated with the Document and Attachment elements in the Blue message 
structures be equal to the identifier used by the profile to identify the 
"attached document", or (b) the profile provide for a mechanism to translate IDs 
used inside the Blue message body into the identifiers it uses to identify 
"attached documents".  I would think (a) would be the better choice, but I 
could conceive of profiles wanting to do (b).

I know this may seem like 
taking a step back (going back to requirements), but I suspect it may just 
formalize something many of us were just assuming to be handled by the 
profiles.  I don't think it adds more than an hour or so of work to the 
spec development 
cycle.
--------------------------------------------------------------------- 
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