legalxml-courtfiling — archive

On Implementation-Specific Data

From: Christopher Durham
To: [email protected]
Date: Thu, 19 May 2005 17:19:00 -0000

MHonArc v2.5.0b2 -->

legalxml-courtfiling message

Subject: On Implementation-Specific Data

From: [email protected]
To: [email protected]
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