OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


Shane,
 
We don't need to try to bend a GJXDM element to suit our needs.  We are free to define additional local types and elements as long as we follow the rules for element naming, etc.  In my opinion, something generic like "implementationSpecificValue" is not compliant with 11179. From 11179-5:
6.1.1 Semantics of name components

Components consist of discrete terms. The components described in this part of ISO/IEC 11179 are:

- object class terms;

- property terms;

- representation terms;

- qualifier terms;

"Implementation" is not an object class and "Value" is not an acceptable representation term.
 
  jim


From: Shane.Durham@lexisnexis.com [mailto:Shane.Durham@lexisnexis.com]
Sent: Thursday, May 19, 2005 3:20 PM
To: legalxml-courtfiling@lists.oasis-open.org
Subject: RE: [legalxml-courtfiling] On Implementation-Specific Data

>>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
 
 
 

From: Cabral, James E. [mailto:JCabral@mtgmc.com]
Sent: Thursday, May 19, 2005 2:32 PM
To: Shane.Durham@lexisnexis.com; legalxml-courtfiling@lists.oasis-open.org
Subject: RE: [legalxml-courtfiling] On Implementation-Specific Data

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]