On Implementation-Specific Data

MHonArc v2.5.0b2 -->
















legalxml-courtfiling message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: On Implementation-Specific Data




From: 
To: 
Date: Thu, 19 May 2005 10:21:57 -0700









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]