It does seem to handle the requirement in
a more standard way.
-----Original Message-----
From: Scott Came
[mailto:scott@justiceintegration.com]
Sent: Monday, May 30, 2005 5: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