[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] On Implementation-Specific Data
Rex,
Answers to your questions are included
below.
jim From: Rex McElrath [mailto:mcelratr@gaaoc.us] Sent: Thursday, May 19, 2005 12:13 PM To: Cabral, James E.; Shane.Durham@lexisnexis.com; legalxml-courtfiling@lists.oasis-open.org 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:JCabral@mtgmc.com] 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.
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] 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):
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'.
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:
2) For each
'blue' XML document, define where in the schema the
'implementationSpecificValue's can be
expressed.
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]