|
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:
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
----- Original Message -----
Sent: Tuesday, May 24, 2005 6:03 PM
Subject: [legalxml-courtfiling] IP issues
involved in the Entity Seal and in other referenced standards
During the last conference call of
the Member Section Steering Committee, we had a lengthy discussion with OASIS
staff concerning the issue of “mismatched” TC IP
policies. John Messing identified
the issue and brought it to our attention. The Electronic Court Filing TC has long taken a very strong position concerning IP
interests in our specifications – we have flat out stated that we will not
include material in our specification if there are proprietary IP rights
attached to it. Courts should not
have to pay royalties for the use of a technology standard, we have
said.
The DSS
TC does not follow our IP approach. They use the standard OASIS RAND policy
– that contributors to a specification must agree to
reasonable and non-discriminatory licensing of their IP rights in a TC standard. In fact, there have been several
statements of IP claims filed with the DSS TC concerning the Entity Seal
specification.
This creates another layer of
issues concerning the use or requirement of the Entity Seal within Court
Filing Blue. The discussion
during the Steering Committee call suggested a number of avenues that we could
pursue. This is my memory and
summary of that discussion. I
invite other Steering Committee members to amplify or correct the
following:
- We will be citing
to a large number of other OASIS standards in our Court Filing Blue
specification – e.g., ebXML, UBL, Entity Seal. We will make use of the WS-I
standards. We use the GJXDM. We
refer to ISO standards. All of
our work derives from the Schema standard of the W3C. In
fact we have no clue what IP issues might lurk
within or might have surfaced regarding all those standards. We do know that all
of the standards developing bodies responsible for creating them did not
follow our IP approach, which is clearly not a universal standard.
However, we have all agreed to
the importance of referencing and using other standards for constructing
Court Filing Blue. Modern
electronic exchange processes depend completely on the use of such
specifications. It makes no
sense to reinvent standards that work perfectly well already. In fact, interoperability would be harmed if we did not use them. The best that we can do in this
situation is to acknowledge in our specification that we make no
representations concerning the IP that might pertain to such standards and
that users of our specification should find out for themselves if they have
any concerns.
- We could review the
existence of IP claims against every other standard that we use and either disclose such claims or refuse to use that
standard because of the existence of such claims. Remember, though, that an IP claim
against a standard is no more than that – a claim. It may actually be groundless. And the
fact that we do not find IP claims is hardly conclusive that there are none.
And we
do not have the time or the resources for such
research.
- We could fudge on
our specification by using language such as “use a standard for locking down
the complete contents of an electronic message using digital signature
technology, such as the OASIS DSS TC’s Entity Seal specification currently in committee
draft form.”
- We could make the
use of other standards, or of other standards that we know have IP claims
against them, non-normative with the use of language such as “implementers
might consider using X” or “we
recommend the use of X,” with a disclaimer about the IP status of the
specification.
- We could attempt to
obtain royalty free licensing commitments from the claimants against a
particular specification that might figure prominently in our work, such as
the DSS.
I regret to inject yet another
troublesome issue into what is already a difficult, extensive and complicated
agenda. But it is clearly there and we need to take it
on.
I invite comments and
suggestions.
John
M. Greacen
Greacen
Associates, LLC
HCR
78 Box
23
Regina,
New Mexico 87046
505-289-2164
505-289-2163
(fax)
505-780-1450
(cell)
john@greacen.net
|