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." <JCabral@mtgmc.com>
- To: <Shane.Durham@lexisnexis.com>,<legalxml-courtfiling@lists.oasis-open.org>
- Date: Thu, 19 May 2005 14:32:17 -0700
Shane,
Using the approach of including local elements in
the Court XML, I see 3 options:
1. The "implementationSpecificValue" element you
propose. I believe this violates the ISO 11179 and Federal XML Developer's
Guide rules regarding using elements rather than attributes, and
using meaningful, unambiguous object names with clear definitions. This
would make Court Filing XML inconsistent with the GJXDM.
2. The "any" element - forget it, it's
a non-starter. It's bad, bad, bad for so many reasons including the
security issues that Don mentioned.
3. Allowing implementations to use the standard GJXDM mechanism for adding local elements through
cascading extensions. We tried it for OXCI - it's doesn't work well
for the reasons I already described.
I
still believe locking down the Court Filing XML schema and allowing a separate
message part with local elements or documents is the cleanest
solution.
jim
>> each
change to the schema forced them to go back and regenerate the
complete set of Java objects.
This scenario might be a reasonable argument for why
we would choose to use pre-defined 'implemetnationSepcificValue' structures in
addition to (or instead of) 'any'-defined elements.
It's been awhile since I used object-from-schema
generators, but I suspect they have issues with 'any'
elements.
>> locking down the common (non-local) court
filing elements in a normative GJXDM-compliant
schema.
I feel that a flexible 'implementationSpecificValue' node
could be considered as locked-down as any other GJXDM
element.
>> 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.
If we used 'message attachments' exclusively, the scenario you describe
is not made any easier, since, without ANY guidance from 'blue', the
format of implementation-specific values is *more* likely to differ between
implementations. Different implementations are more likely to select
entirely different formats for their extensions.
However, if generic 'implementationSpecificValue' nodes were available,
then, at the least, there *might* be some kind of semi-standard for the
implementation-specific data.
That said, it is a moot point to discuss the advantage of one technique
over another, with respect to interoperability among differing
implementations. The different implementations will
probably have extensions that are entirely meaningless to one another.
That's why I keep calling it 'implementation-specific' values,
eh?
>> The primary argument against the current
proposal
I want to stress that I am not against the current proposal - except that
it is defined as the *only* way to provide implementation-specific values.
Likewise, I would not want to see the proposed
'implementationSpecificValue' nodes as the *only* way to provide
implementation-specific data.
There's a time and place when implementers will need to use BOTH
approaches.
- Shane
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.
1111 Third
Avenue, Suite 2700
Seattle, WA 98101-3201
(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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]