legalxml-courtfiling — archive

Re: [legalxml-courtfiling] IP issues involved in the Entity Seal and in other referenced standards

From: Dallas Powell
To: [email protected]
Date: Wed, 25 May 2005 22:42:00 -0000

MHonArc v2.5.0b2 -->

legalxml-courtfiling message

Subject: Re: [legalxml-courtfiling] IP issues involved in the Entity Seal and in other referenced standards

From: "Dallas Powell" <[email protected]>
To: <[email protected]>,"Electronic Court Filing Technical Committeee" <[email protected]>
Date: Wed, 25 May 2005 16:40:06 -0600

I agree with John Messing about the excellent description John Greacen has written regarding the IP issues we face. I would like to introduce what I see as a hole in the current wd-LegalXML-Specifications-02 requirements and how this affects our view of IP, and our use of other standards.

During the call that John refers to below, we were told that there are several versions of SOAP and that some of them have IP issues. I suspect that none of the SOAP versions adhere to our IP policy.

As part of my review of the wd-LegalXML-Specifications-02 I have been trying to look back at our notes to see what holes we found in LegalXML 1.1 and how the new requirements fulfills what was previously lacking.

One hole that I have identified has to do with application layer information.

We have found that it is critical to include in each message, application information and version controls. There are several levels of information need. They are:

1) The fact that the message we are receiving is a LegalXML message to differentiate from other GJXDM related messages.

2) Version control of LegalXML. We must provide means to know what schema to use, whether it is LegalXML1.1, LegalXML Blue 1.0, 1.1 and so forth so that we can parse the message against the correct schema.

3) Court Policy controls. A Filing Review MDE may be servicing several CMS systems, and each system may have a different policy. This may be a parsing issue, but also aIn addition to the policy, each policy will need version controls.

4) I am not sure if we need some controls that identify which GJXDM schema and subschema we are using and the versions for documents that we might embed that are XML based documents using GJXDM?

In previous meetings we have suggested that we abandon the LegalXML element (tag name) and substitute it with the SOAP BODY element name. I said that I would agree as long as we could make it work. Now I see that we need to make a choice and either reverse our decision or adopt all of SOAP as a required part of the standard with all its IP issues and abandon our purest position on IP.

Here is an example of the application layer information and how it is embedded in this SOAP Header. This example comes from the W3C Primer section of SOAP:

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
          env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
   <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="http://mycompany.example.com/employees"
          env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
           env:mustUnderstand="true">
   <n:name>�ke J�gvan �yvind</n:name>
</n:passenger>
</env:Header>
<env:Body>

This XML example demonstrates the application and version control of this XML instance:

<?xml version='1.0' ?>.

It identifies the application layer of SOAP and maybe version control if the date is considered the control:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

It identifies the application layer of the travel agency but no version control:

<m:reservation xmlns:m=http://travelcompany.example.org/reservation

LegalXML needs an application and version control identifiers. In addition, we need Court Policy identifiers and version control especially if one Clerk Review MDE supports more than one CMS.

We have abandoned the LegalXML element which never had enough information anyway, however, unless we retrieve it and add to it, we are going to have to do something else. If we follow our pattern of depending on SOAP, this means we are going to adopt more than just the Body element. We now need to adopt the SOAP Header.

If we reverse our position and create a LegalXML element with additional controls needed then LegalXML can stand on its own. If we adopt SOAP headers then we have created a standard that is dependent on, or requires another standard that does not adhere to our IP policies.

Dallas