legalxml-courtfiling message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: On Implementation-Specific Data
- From: Shane.Durham@lexisnexis.com
- To: legalxml-courtfiling@lists.oasis-open.org
- Date: Thu, 19 May 2005 10:21:57 -0700
This post is to help us discuss and select an approach
for how an implementer can express implementation-specific (non-normative) data
in 'blue' messages.
Quick Background:
The existing proposal is that additional data is to be
expressed in a separate data file, and included as a 'message attachment' of the
blue message.
By 'message attachment', I mean some generic blob
of data that is included with the message, in a manner that is specific to the
implementation's profile. I am not at all referring to the functional
concept of 'attachment' (aka 'supporting document').
* I am in favor of 'blue' permitting/supporting the use
of 'message attachments' for implementation-specific data.
** I am NOT in favor of using 'message
attachments' as the *only* way to express implementation-specific
data.
At Issue:
My beef
(if you want to call it that), is that in *some* implementations, the
implementation-specific data could be very simple and minimal. And, it
could be unnecessarily inconvenient for our schema to insist that the
additional data always be expressed and managed as a separate 'message
attachment'.
For example, consider if the 'Filing
Assembly' MDE is required to transmit the GPS coordinates
(latitude/longitude) of the filer. (yes, I picked a very silly example
- trying to imagine something that is very unlikely to be in the current
schema):
To transmit these simple values as a 'message
attachment', the 'Filing Assembly' must produce 2 data files,
instead of one. Though, difficult to quickly describe here, I think we
can all agree that it would be much easier to create and manage a
single output file rather than two. (especially, if your existing
system already produces a single output file, and all you really want to do is
transform it into the desired 'blue' format).
To receive this data, it is inconvenient for the
'Filing Review', component to receive and manage two data files, and
re-assemble them into some (undefined) singular unit for the clerk to
review.
If this implementation-specific data is to be
docketed, then, presumably, the process of pulling the re-assembled
data files apart, transmitting them again as two files, and then re-assembling
the data file will repeat itself as the filer's data is passed among the
MDEs of the overall system.
One might say that the inconveniences I described above
are not all that different than the hoops we must jump through in
order to associate a 'blue' XML filing document with the filer's documents
(documents are often expressed as 'message attachments')
However, for filer's documents, the hoops
we jump through are reasonably justifiable and somewhat unavoidable
-implementers have found that large binary documents do not always
travel well as embedded data within an XML document.
With respect to a filer's documents, there is a
specific technical hurdle driving our expression of a filing as multiple
data files.
The same could not be said of my
hypothetical example of GPS coordinates. For these simple data values,
there is no technical hurdle, or advantage, that demands we express simple
implementation-specific values as 'message
attachments'.
Proposal:
I propose that the schema should permit the
implementer to include some implementation-specific data directly in the
blue XML document.
Strawman:
1) Define (or identify an
existing) 'implementationSpecificValue' element, which we would
functionally declare to be non-normative. It
could consist of:
- Some flexible set of
name/id/code/codeDescription/value properties, permitting the implementer
to express basic and common data values.
Example
<implementationSpecificValue
name="FilerGPS" value="N 49 14.482 / W 123 9.555
/>
AND/OR
- An 'any'-defined element, permitting the
implementer to express very complex data values using the full vocabulary of
XML.
Example: <implementationSpecificValue><FilerGPS>N
49 14.482 / W 123 9.555</FilerGPS>
</implementationSpecificValue>
2) For each 'blue' XML document, define where in the
schema the 'implementationSpecificValue's can be
expressed.
- We could create an all-encompassing
'implementationSpecific' section at the end of every 'blue' message, where the
implementer can tuck all of their implementationSpecific
data.
AND/OR
- We could lightly-and-smartly sprinkle
'implementationSpecificValue's throughout the schema, to allow the
implementer to more readily associate to implementation-specific data
with targeted portions of the 'blue' XML message.
For example, we could
include an 'implementationSpecific' section among the 'blue' structures
representing a person, so that implementation-specific data can be
tightly related to a particular person. Likewise for the sections
representing cases, document-info, attorneys,
etc.
I think that with the use of BOTH 'message attachments'
and direct 'implementationSpecificValue' nodes, the implementer will have the
flexibility to express implementation-specific values in whatever manner is
appropriate.
- Shane Durham
LexisNexis
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]