legalxml-courtfiling — archive

RE: [legalxml-courtfiling] On Implementation-Specific Data

From: James Cabral
To: [email protected]
Date: Thu, 19 May 2005 19:24:00 -0000

MHonArc v2.5.0b2 -->

legalxml-courtfiling message

Subject: RE: [legalxml-courtfiling] On Implementation-Specific Data

From: "Cabral, James E." <[email protected]>
To: "Rex McElrath" <[email protected]>,<[email protected]>,<[email protected]>
Date: Thu, 19 May 2005 12:24:10 -0700

Rex,

Answers to your questions are included below.

jim

From: Rex McElrath [mailto:[email protected]]
Sent: Thursday, May 19, 2005 12:13 PM
To: Cabral, James E.; [email protected]; [email protected]
Subject: RE: [legalxml-courtfiling] On Implementation-Specific Data

Jim and Shane,

From just reading over the two sides, I would have to side more with Shane’s viewpoint in this matter. With the multitude of courts and court policies, it seems reasonable to expect new fields to be needed within the XML and not in an attachment. Also, what context are the extended elements in the attachment?

The context for extended elements is implementation-specific.

If the extension is a minor extension of a base element in the schema, will the implementer be required to include redundant fields in the attachment as well? For example, what if an extension of case participants was required? Would there have to be case participants in both the court filing XML and as extended case participants in the attachment?

If the issue at hand is interoperability, then can we not specify rules for extending the schema that would allow for a base level of interoperability?

-Rex

Administrative Office of the Courts

404-657-9218

From: Cabral, James E. [mailto:[email protected]]
Sent: Thursday, May 19, 2005 2:39 PM
To: [email protected]; [email protected]
Subject: RE: [legalxml-courtfiling] On Implementation-Specific Data

Shane,

Thank you for helping to get this discussion started. I am happy to provide the counterpoint in defense of the current proposal.

The challenge we are facing is achieving the correct balance of flexibility and interoperability:

1. At one extreme, if we leave everything open, we will never achieve interoperability as everything will be open to interpretation and modification and impossible to implement completely.

2. At the other extreme, if we lock everything down and do not provide any extension mechanisms, complete compliance with the standard and interoperability will be easy to implement but the implementations will be useless as they will not meet the business requirements in most applications.

Clearly, neither extreme is workable. We attempted an approach similar to the first extreme in OXCI and Counterclaim discovered that each change to the schema forced them to go back and regenerate the complete set of Java objects. Considering that this recoding/regeneration would be necessary for each set of local extensions, using this approach clearly does not provide a robust solution.

The current proposal attempts to achieve the necessary balance by:

1. Ensuring a baseline level of interoperability in all Court Filing Blue implementations, including off-the-shelf products, by locking down the common (non-local) court filing elements in a normative GJXDM-compliant schema.

2. Allowing each implementation to support additional local elements in a separate part of the message that may be in any XML or non-XML format. Some implementations may use XML for these elements - in that case, they should use GJXDM-compliant schemas. Some implementations may use a court-specific cover sheet (e.g. Word or PDF). Some implementations may not require any additional elements.

The primary argument against the current proposal seems to make the assumption that most implementations will use XML for describing local elements and questions the need for two XML objects in these implementations. My response is that we should try to define a single extension mechanism that supports all implementations including those that do not use XML for describing local extensions. By introducing both XML-specific and general extension mechanisms, we further complicate interoperability because different implementations may choose to support one mechanism rather than the other.

Jim Cabral

James E. Cabral Jr.
MTG Management Consultants, L.L.C.

(206) 442-5010
www.mtgmc.com

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer.

From: [email protected] [mailto:[email protected]]
Sent: Thursday, May 19, 2005 10:22 AM
To: [email protected]
Subject: [legalxml-courtfiling] On Implementation-Specific Data

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

This e-mail and any files transmitted with it are intended solely for
the use of the entity or individual(s) to whom they are addressed and
not for reliance upon by unintended recipients. If you are not the
intended recipient or the person responsible for delivering the e-mail
to the intended recipient be advised that you have received this e-mail
in error and that any use, dissemination, forwarding, printing, or
copying of this e-mail and any files transmitted are strictly
prohibited. If you have received this e-mail in error please delete the
entire email and immediately notify us by email to the sender or by
telephone to the AOC main office number, (404) 656-5171. Thank you.