I think that Serguei is correct
in his assessment and that has been a struggle for us as well.
Dallas
From: legalxml-courtfiling@lists.oasis-open.org
[mailto:legalxml-courtfiling@lists.oasis-open.org] On Behalf Of Serguei
Mysko
Sent: Sunday, September 23, 2012 4:22 PM
To: Joe Mierwa
Cc: legalxml-courtfiling@lists.oasis-open.org
Subject: Re: [legalxml-courtfiling] FW: ECF Schema Related Question
Joe,
I don't think ECF spec will ever get the same level of attention, participation
and enthusiasm as with Apache Hadoop, Ubuntu or even OASIS AMQP.
That's why I see your input as valuable; we all need to exchange with opinions
more often than we do.
I had similar questions myself, scratched my head:
- Why would they (OASIS, NIEM) do it this way? Gee!
Just to later 'unscratch' it:
- Well, that was smart on their side, I did not see it from the beginning.
In other cases - no 'unscratching' took place - my schema extension would
resolve the issue.
What I am saying, cardinality, missing elements, additions and alike - there
are solutions.
1. Don't forget about the Subset.zip archive: http://docs.oasis-open.org/legalxml-courtfiling/specs/ecf/v4.0/ecf-v4.0-spec/xsd/
You may want/need to augment/modify it.
2. You can use substitution groups to have it your way.
The two are better solutions to an alternatively would be rigid ECF spec
decision on cardinality, set of elements.
Example:
Say, you are providing solution to X number of Courts, all with similar
requirements as for Lead/Connected docs, cardinality being one of them.
Use the (1) and (2) to get common schema, the way it fits better the Courts.
The point here is that ECF spec or any other one in the field would never be at
the same level as HTTP or TCP protocol specifications regarding normative vs
informative.
One has to decide first what is normative, a must/optional, etc., for each
particular business model.
The primary difference is that HTTP/TCP deal with a single domain, ECF has to
'please' a great number of domains.
-
Serguei
On 9/23/2012 12:59 PM, Joe Mierwa wrote:
Hi Sergui,
Thanks for the clarifications. I am not saying that there is something wrong with the spec the way it is with the exception of stating that at the very least, the impact to the architecture is something that should be explicit and not implicit. To me, that is the core issue. A specification with implicit requirements affecting the architecture or behavior is incomplete in my opinion.
Also, if there is no hard and fast reason readily explaining the rationale for the cardinality difference (although those discussions are probably lost in the mists of time), then re-visiting the cardinality as a discussion point is worthwhile.
I can see that from an interoperability perspective, it is not necessarily a bad thing to have the cardinality locked down the way it is. But it does seem to me that with the FRMDE solely dictating the single/multiple lead document cardinality the way it does would seem to limit the scalability of the architecture. How appreciably it might impact the scalability is hard to predict, but regardless, as long as the spec is clear regardless of whether it is normative or informative, is the important thing.
From: Serguei Mysko [mailto:sergueim@intresys.com]
Sent: Saturday, September 22, 2012 1:36 PM
To: Joe Mierwa
Cc: legalxml-courtfiling@lists.oasis-open.org
Subject: Re: [legalxml-courtfiling] FW: ECF Schema Related Question
Hi Joe,
Let's look at some related steps in the process.
Step 1. EFSP (FAMDE) prepares a filing with possibly multiple LeadDocs, each optionally having a number of ConnectedDocs.
Q: Where will the related XML elements appear in the filing message?
A: Under CoreFilingMessage element.
There will be at least one Lead and zero or more Connected:
<xsd:element ref="FilingLeadDocument" maxOccurs="unbounded"/>
<xsd:element ref="FilingConnectedDocument" minOccurs="0" maxOccurs="unbounded"/>
Q: Having a list of Leads, followed by a list of Connected, how do I know which Lead a Connected doc relates to?
A: By uniquely identifying each doc in its s:id attribute; Connected points to the Lead, by specifying Lead's id in ParentDocumentReference element.
Example:
<FilingLeadDocument s:id="Lead1">
<FilingLeadDocument s:id="Lead2
<FilingConnectedDocument s:id="Connected1">
<!-- skipped -->
<ecf:DocumentMetadata>
<ecf:ParentDocumentReference s:ref="Lead1"/>
<!-- skipped -->
Q: How Court policy may affect, in the context?
A: FRMDE 'knows' about particular Court Policy.
EFSP may, not required, request Court Policy.
The policy could say, for example: 2 Leads at most; a Lead cannot exceed 5 MiB.
EFSP then is to follow the policy. But it may want to ignore :-)
All in all, at step 1 we've got CoreFilingMessage describing Leads and Connected ready for submission.
So far, we were with Core spec only.
We have not touched the transport level, Service Profile, yet.
Step 2. Filing arrives for review or a configuration allows an auto-accept.
FRMDE is to prepare RecordFilingRequest (RFR) to be submitted to CRMDE.
A number of operations may take place here, e.g. change doc title, reject Connected, digitally sign, etc.
Q: Where will we see the results of the actions/operations taken?
A: Under RecordDocketingMessage (RDM) element.
We would get, for example:
<RecordDocketingMessage>
<ReviewedLeadDocument s:id="ReviewedLead1" s:ref="Lead1">
<ReviewedConnectedDocument s:id="ReviewedConnected1" s:ref="Connected1">
</RecordDocketingMessage>
The RFR created goes to CRMDE.
End of step 2.
We were discussing the Core spec, XML structure.
One may argue that a different layout would be better.
If we think though in terms of XPath - it does not really matter.
What is important is that we preserved original filing info and added review results into RFR.
Q: Did we break the 'harmony' with CFM <=> RDM, from a Court Policy perspective?
A: I don't think so. What Court will be looking at is the review result - the RDM.
Say, Court Policy tells the Court won't ingest attachments (connected docs).
EFSP however submitted few.
The info about attachments will appear under CFM (as per original filing), but not under RDM.
Please note, the auto-acceptance does not mean FRMDE will not apply a number of rules/procedures (verification as one, doc formats as another) to create RFR.
The 'auto' means no human operator.
Next aspect mentioned, (in)efficiency of the Web Service Profile, which is another spec.
Personally, I dislike having huge (MiB) web service requests for tech reasons.
Here at Intresys we use MQ profile instead.
With WS Profile, one still could use FTPS to upload documents and have light (KiB) web service requests.
Altogether.
EFSP may know Court Policy or not.
EFSP may follow it or not.
FRMDE regardless will have to verify.
FRMDE may reject or correct the filing.
Up to this stage: What's wrong with the spec?
FRMDE prepares RFR by including original filing info (CFM) as well as the results of clerk review or automatic corrections under RDM.
At this stage: What's wrong with the spec?
Joe, I might missed some of your points, please feel free to ask/correct me.
One thing that makes me confident - it works, in production, for a year+.
Respectfully,
-
Serguei
Intresys
On 9/22/2012 9:59 AM, Joe Mierwa wrote:
Hi Sergui,
I don’t fully understand your perspective. Can you please elaborate?
Also, my perspective centers on cases where auto-accept is permissible. Consider a criminal case with related motions and notices in one filing package. In this scenario each motion is a lead document with its associated notices, affidavits , etc., as connected documents. From an architectural perspective, it seems to me that it will inefficient in certain implementations. I refer specifically to web services with all of its attendant overhead.
There would also be an incongruence with the part of the spec (Court Policy Response Message) that specifies whether multiple lead documents in a filing are acceptable. As it is currently documented, it does not explicitly qualify the MDE to which the policy applies. I take that to apply to both CFM and RDM equally.
Thoughts?
From: Serguei Mysko [mailto:sergueim@intresys.com]
Sent: Saturday, September 22, 2012 1:22 AM
To: legalxml-courtfiling@lists.oasis-open.org
Subject: Re: [legalxml-courtfiling] FW: ECF Schema Related Question
Hi,
Looking from ECF v.4 spec perspective.
There can be a specific Court review procedure.
So, for example, out of 5 originally filed docs (under the CoreFilingMessage), only 2 would be reviewed - to appear under RDM, better to say - multiple RDMs.
How else, if a doc upon review would get a different title, case type or else?
A Court may follow an auto accept (no review) for some case types as well.
I don't see an issue with ECF v.4.
-
Serguei
Intresys
On 9/21/2012 9:13 PM, James E Cabral wrote:
Joe Mierwa noticed a discrepancy in the number of lead documents allowed between the CoreFilingMessage and RecordDocketingMessage. I think this is worth a discussion for ECF 4.1.
Jim Cabral
MTG Management Consultants, L.L.C.
www.mtgmc.com
(206) 442-5010 Phone
(502) 509-4532 Mobile
Helping our clients make a difference in the lives of the people they serve.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer.
From: James E Cabral
Sent: Saturday, September 22, 2012 12:13 AM
To: 'Joe Mierwa'
Subject: RE: ECF Schema Related Question
Joe,
This question really tests my memory. Reviewing the ECF 3.x and 4.x schemas, I verified that we have allowed multiple lead and connected documents in CoreFilingMessage all the way back to ECF 3.0. In ECF 3.x, RecordDocketingMessage allowed for multiple “reviewed” documents without distinguishing lead from connected documents. In ECF 4.0 and later, however, we changed ReviewDocketingMessage to allow one lead and multiple connected documents. Why exactly we didn’t allow multiple leads in ECF 4.0, I can’t say for sure. For now, I think your analysis is correct – you would need to call ReviewDocketingMessage multiple times in the case of a CoreFilingMessage with multiple lead documents. But I think it is worth discussion with the TC as to whether that makes sense for ECF 4.1 and beyond.
Jim Cabral
MTG Management Consultants, L.L.C.
www.mtgmc.com
(206) 442-5010 Phone
(502) 509-4532 Mobile
Helping our clients make a difference in the lives of the people they serve.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer.
From: Joe Mierwa [mailto:Joe.Mierwa@urlintegration.com]
Sent: Friday, September 21, 2012 5:50 PM
To: James E Cabral
Subject: ECF Schema Related Question
Hey,
I only just noticed/realized that the CoreFilingMessage allows for multiple lead documents while the RecordDocketingMessage only allows 1 lead document. The net effect is that the Filing Review MDE would need to invoke the Court Record MDE once per lead document. Is that correct? If so, I would assume that the rationale is that if the clerk is reviewing each lead as a separate package then each would be approved singly resulting into a filing into the court record.
Does that sound about right?
Joe Mierwa
CTO
URL Integration, Inc.
9780 Mount Pyramid Court
Suite 250
Englewood, CO 80112-7060
http://www.urlintegration.com
Joe.Mierwa@urlintegration.com
Office: (303) 799-4585 x119
Mobile: (919) 523-2224
Fax: (303) 708-1737
Stay Connected:
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
