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: Shane.Durham@lexisnexis.com
- To: legalxml-courtfiling@lists.oasis-open.org
- Date: Thu, 19 May 2005 15:20:28 -0700
>>using meaningful,
unambiguous object names with clear definitions. This would make Court Filing
XML inconsistent with the GJXDM
<<
I don't see it as
ambiguous.
I think that
'implementationSpecificValue' says exactly what it is - a piece of data, that is
specific to the implementation.
Within that data-item, there
are unambiguous details about the data item, including its name and
value.
>>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. <<
I don't know that I disagree with you, with respect to
the cleanliness of what you are advocating.
Less flexibility usually makes the system easier to
describe and to implement.
However, I think, in this instance, we
must try to support an approach to implementation-specific data
that is a little more convenient to use. It's a matter of
practicality.
>> 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
<<
Not a big deal as to whether
we use element/text() nodes or attribute="" approach.
Whatever we feel would
be consistent with the existing GJXDM.
Maybe we might find an
existing GJXDM element that fits closely with what we need
here?.
-
Shane
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]