RE: [legalxml-courtfiling] Document identifiers

MHonArc v2.5.0b2 -->
















legalxml-courtfiling message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: RE: [legalxml-courtfiling] Document identifiers




From: 
To: 
Date: Wed, 1 Jun 2005 10:53:48 -0700 









>> 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:]
Sent: Monday, May 30, 2005 2:37 PM
To: 

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 













[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]