MHonArc v2.5.0b2 -->
legalxml-courtfiling message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [legalxml-courtfiling] On Implementation-Specific Data
From: "Cabral, James E." <>
To: "Rex McElrath" <>,<>,<>
Date: Thu, 19 May 2005 12:24:10 -0700
Rex,
Answers to your questions are included
below.
jim
From: Rex McElrath [mailto:]
Sent: Thursday, May 19, 2005 12:13 PM
To: Cabral, James E.;
;
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:]
Sent: Thursday, May 19, 2005 2:39
PM
To:
;
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:
[mailto:]
Sent: Thursday, May 19, 2005 10:22
AM
To:
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]
