Since OXCI is not actually the standard, and
there are some members of the committee that consider OXCI to be nothing more
than another competitor, I do not think it is appropriate to call for a vote
from the TC on OXCI specific issues. I am sure that none of us mean
to, but it seems as though it is happening.
I realize that OXCI is experiencing issues
that may affect all of the committee members, and for this reason I
participate on calls specific to OXCI but, I do not believe the committee
was established to assist OXCI, so I do not feel that OXCI specific calls
should be considered official meetings of the TC.
As for the envelope, the only reasoning that I
can see that OXCI dropped it, is because ebXML has some elements that the ECF
1.1 envelope has ( but by no means all of them), and GJXDM has some elements
that the ECF 1.1 envelope has ( but not all of them). I read
the architectural document on OXCI and could
find no other valid reasoning.
However there are several other communication
methods that are included in the current vision of Blue which do not support
ebXML, and many courts that will not be receiving GJXDM document
instances for some time. In addition, currently functioning
products cannot afford to abandon existing courts nor court customers
with communication methods already functioning, and force them to adopt a
new communications method just because OXCI does not feel there is a need for
an envelope.
It will be far easier for existing courts
and integrated partners to modify an envelope than to change communications
methods. Such a change would force the courts and integrated partners to
abandon their existing architecture and move to a new one, and this motivated
by one EFM that does not deal with current customer issues. I think this
is a bad choice.
My point with the envelope is that there are more
than technical issues that should be considered, however I will post my technical reasons why the envelope
should not be abandoned as well.
I am concerned about the statement that ....Jim
would like to receive other comments on:
-
whether Court Filing Blue should
contain a required or specified envelope (an issue discussed during the
Tuesday teleconference),
-
whether his proposal for handling
fees is adequate, and
-
the feasibility of
Allen Jensen’s
recommended way of dealing with firewall security at the interface between
OXCI and the court’s case management information system data base (an issue we
did not reach on Tuesday).
Although I am sure your intent was not to make it
sound like Jim and OXCI will decide what to do with the standard, whether to
keep the envelope or not, but it sure sounds like it when you read
it.
As for handling fees, the TC needs to
agree on the Schemas that are needed and not the architectural issues of how a
product will utilize the schemas. One schema should represent information to
allow the EFM to charge for fees, and another schema should represent how the
EFSP charges for fees and communicates the information it collected to
the EFM. Another schema should include information that is sent back to
the filer that paid the fee to identify how much was charged, against what
case number, when it was charged..... and this might be supported in both
cases whether the EFM or EFSP charges. I will the elements and
definitions in a schema format that we use for processes court processes to
make the charges after it passes through the EFM, and how we encrypt the data
for protection when we include it in the envelope.
For what its worth, I do believe that users
logging in directly to the EFM as pointed out by Alan can be a danger to a
network, and I do think that Alan's design to hide the internal EFM is
feasible and appropriate for a more secure system. I also believe that
multiple EFMs should be able to communicate to each other, but I also believe
that this is an architectural issue and not a TC issue. The API to
communicate to the EFM is what the TC must focus on for interoperability, not
the architecture. Alan's security model is an excellent
architectural proposal and could be considered for an API on the back
side of the EFM rather than the front side where an EFSP
communicates.
Dallas
exist still need to maintain those communication
methods
----- Original Message -----
Sent: Thursday, February 26, 2004 11:42
PM
Subject: [legalxml-courtfiling]
Cancellation of proposed ballot on OXCI options
Jim Cabral passed
on the gist of the TC’s Tuesday discussion to the OXCI project
managers. He also received additional guidance from GTRI on the
generation of GJXDM subschemas and validated the Amber Alert subschema
posted by GTRI.
Based upon the discussion, and
upon the additional information provided by GTRI, OXCI has decided to pursue
option 2 without waiting for GTRI to produce a subschema generator – instead
developing GJXDM subschemas for OXCI following the guidance provided by
GTRI. Jim Cabral will be
developing the proposed subschemas over the course of the next
week.
Jim would like to receive other
comments on the draft schemas that he previously posted on the Sourceforge
website. He would specifically like to receive further comments on
three additional issues:
-
whether Court Filing Blue should
contain a required or specified envelope (an issue discussed during the
Tuesday teleconference),
-
whether his proposal for
handling fees is adequate, and
-
the feasibility of
Allen Jensen’s
recommended way of dealing with firewall security at the interface between
OXCI and the court’s case management information system data base (an issue
we did not reach on Tuesday).
I encourage discussion on each
of these issues on the TC listserve. I will make them discussion items
for the next teleconference scheduled for next Tuesday.
Because OXCI has decided on the
direction it will pursue, there seems to be no point in pursuing a TC ballot
on the matter.
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)