[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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? 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:JCabral@mtgmc.com]
Sent: Thursday, May 19, 2005 2:39
PM
To: Shane.Durham@lexisnexis.com;
legalxml-courtfiling@lists.oasis-open.org
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:
Shane.Durham@lexisnexis.com [mailto:Shane.Durham@lexisnexis.com]
Sent: Thursday, May 19, 2005 10:22
AM
To:
legalxml-courtfiling@lists.oasis-open.org
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]