[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] Timestamps
Murray,
Good to hear from you guys! Thanks for the insights.
>> we do populate the Submitted element.
...with the Date/Time (GMT) of the file upload to the filing assembly module.
You have used a document's 'Submitted' element to represent when a filer uploaded a document to your service. That sounds like a reasonable interpretation to me.
I happen to use that node differently - I use it to express the AuthorizedTime - when a filer authorized the filing to be sent. We (FileAndServe) include the same authorized timestamp on all documents, but, in practice, I think only the leadDocument's timestamp is ever consumed.
>> If there were a "Submitted" element at the "envelope" level we would use it.
I take that to mean, you might also have expressed an AuthorizedTime had there been an obvious, well-defined place to include it.. (and/or an explicit requirement).
And, I might guess, that since the AuthoriedTime was not present in your messages, the courts chose to consume your messages' 'CreationTime' because, that happened to be the closest value.. in terms of physical time, and in terms of functional purpose. ( Robert O'Brien can shed some light on that aspect. )
>> "Submission" might be construed as potentially occurring at more than one point in time, particularly in an architecture where reception is not guaranteed and re-submission must be possible.
That's kinda why I avoid using that term in discussions.
It's meaning is too much 'in the eye of the beholder'.
At a glance, it might mean any of these:
- When the message was authorized. ("The filer submitted the data at this time")
- When the message was sent. ("The system submitted the message at this time")
- When the message was received. ("The system received a submission at this time.")
I prefer to use other terms when discussing the functional concepts.
However, when it comes time to give a name to an XML node, I tend to get just a little less fussy.
(Well, only a little less... )
Thanks again for the information.. And the DTD!
- Shane Durham
-----Original Message-----
From: McDonald, Murray (LNG-CAN)
Sent: Wednesday, October 12, 2005 1:31 PM
To: Durham, Shane (LNG-SEA); robert.obrien@cas-satj.gc.ca
Cc: legalxml-courtfiling@lists.oasis-open.org; Cottee, Dave (LNG-CAN); Magee, Patrick (LNG-CAN); Guylaine Papineau (guylaine.papineau@cas-satj.gc.ca)
Subject: RE: [legalxml-courtfiling] Timestamps
Shane, Robert
We are using a slightly modified version of the 1.0 DTD originally identified as "PS_10001_2000_07_24". I have attached the DTD for your convenience.
I haven't really been keeping up to date with later versions of the DTD so I have no idea how "applicable" my comments are to more current versions of the DTD.
In this DTD the "Submitted" element is a required child element of the "DocumentInformation" and the "AttachmentDocumentInformation" elements.
As such, we do populate the Submitted element. Its child Date/Time elements are populated with the Date/Time (GMT) of the file upload to the filing assembly module. This is, admittedly, not terribly useful information.
The "Creation" element is a required child of the root element and its child Date/Time elements are populated with the Date/Time (GMT) of the original attempt to submit the envelope to the Court.
Is this the correct "functional distinction"? I think the question is open to interpretation. The main reason we chose to use the "Creation" element for the time of submission is because it applied at the "envelope" level and the unit of submission is the entire envelope. This seems to be a logical "fit".
If there were a "Submitted" element at the "envelope" level we would use it. I believe there would still be some argument as to what the "appropriate" use of the element should be.
If one had both a "Creation" and a "Submitted" element at the envelope level one might take the position that the "Creation" element should hold the Date/Timestamp the envelope was originally "created" (ie authorized by the user for submission to the court) and the "Submitted" element could be used to hold a Date/Timestamp of submission to the Court by filing assembly. In this case a "resubmission" task that is capable of retrying submission in the event of an "EFM" outage would adjust the "Submitted" element on each resubmission attempt.
To my mind, "Creation" is an action that takes place at one specific point in time whereas "Submission" might be construed as potentially occurring at more than one point in time, particularly in an architecture where reception is not guaranteed and re-submission must be possible.
We are open to any semantical interpretation of the DTD element usage provided the interpretation is non-ambiguous.
Murray McDonald
Vice President, Systems
Email: Murray.McDonald@lexisnexis.ca
Phone: (613) 549-4611
LexisNexis Canada Inc.
Quicklaw ** Butterworths ** LexisNexis
-----Original Message-----
From: Durham, Shane (LNG-SEA)
Sent: October 12, 2005 1:20 PM
To: robert.obrien@cas-satj.gc.ca
Cc: legalxml-courtfiling@lists.oasis-open.org
Subject: RE: [legalxml-courtfiling] Timestamps
Robert,
I have this follow-up question:
How did the court decide to use Creation time?
Do you think your implementation intentionally chose to use that value
rather than the 'Submitted' timestamp ?
Note: 'Submitted' is expressed in LegalXML 1.x for each document. As I use
it for 'FileAndServe' customers, it represents the time when a filer
authorized the filing to be sent.
Or, perhaps the court through that 'Creation' just looked like the right
value to use and no one really considered what it represented.
Did anyone at the court consciously consider:
"We definitely want to use the Creation time.
And we definitely do NOT want to use the Submitted time"
Maybe the court was unaware of the functional distinction?
Or, maybe LexisNexis CA didn't provide both values in the XML, and so, the
court had no choice to make.
Eh?
- Shane
-----Original Message-----
From: Robert O'Brien [mailto:robert.obrien@cas-satj.gc.ca]
Sent: Wednesday, October 12, 2005 9:10 AM
To: Durham, Shane (LNG-SEA); JCabral@mtgmc.com
Cc: legalxml-courtfiling@lists.oasis-open.org
Subject: Re: [legalxml-courtfiling] Timestamps
Shane, Jim et al
Re: Authorized Timestamp
To clarify further, I have talked to LexisNexis Canada about what
I mentioned yesterday during the call that here at Federal Court in
Canada, and they confirm that the most 'significant' date/timestamp in
the envelope is the one that appears within the "<creation>" element (in
Court Filing 1.0) which is a direct "child" of the root "LegalEnvelope".
For example:
<LegalEnvelope Version="1.0">
<MessageIdentification>LNC.2005-110-00001-00</MessageIdentification>
...
<Creation>
<DateTime>
<Date>20051011</Date>
<Time>17:19:54Z</Time>
</DateTime>
</Creation>
<PaymentInformation>
...
</LegalEnvelope>
The "creation" date time stamp is assigned to an envelope only AFTER
the EFSP has completely constructed the envelope and is ready to
transmit the envelope to the court (all documents and attachments have
been uploaded, they've gone to the online payment entity and back if
required, etc). The assembled envelope is written to disk storage at
the EFSP as an XML "file".
They then attempt to send the envelope to the EFM. If the EFM
acknowledges successful receipt of the envelope we are done.
If the send does not receive a positive acknowledgment of successful
processing by the EFM, the EFSP's regularly scheduled "resubmission"
task will "find" the envelope in the "submissions pending" queue and
will retry submission of the envelope -- every 15 minutes.
The envelope contents are NEVER altered on such a "resubmission".
Unless the "problem" turns out to be that the EFSP created an invalid
envelope -- in such a case they might have to "fix" the envelope by hand
-- but they would NOT adjust
the date/time stamp. In other words, the "original" creation date/time
stamp remains what was originally assigned by Filing Assembly MDE.
And that is what the Court here is using as determinative of the filing
date, as requested and agreed upon by the Bar. So it is not simply when
the filer "authorizes" the filing, nor is it simply when the EFM or
Filing Review actually receives it.
Sorry for the length of this, but it is important to keep what we use
in our 1.0 implementation available in version 3.0 of the standard ....
>>> <Shane.Durham@lexisnexis.com> 05/10/11 5:44 PM >>>
Jim, et al,
Authorized Timestamp
The document that I posted on 9/26/2005 contains this working
definition of
what I have called 'Authorized Timestamp' (call it what-you-will).
The time when a user approved (released) a filing to be sent to the
FilingReview process.
As we discussed on the conference call, this value could be generalized
and
made applicable to all messages. In that case, a generalized
definition
might be:
The time when a user or process approved (released) this message data
to be
transmitted to a recipient MDE.
The important aspect of the definition, it that we understand this
value is
not synonymous with 'MessageAssembled timestamp' (n/a), 'MessageSent
timestamp', or 'MessageReceived timestamp', although, in some
systems,
these timestamps might all be equal.
FilingReviewedTimestamp
In that 9/26/2005 document, I suggested that we should have a place to
express the time at which a clerk decided to accept or reject a filing.
In
that 9/26/05 document, I proposed this draft definition of
FilingReviewedTimestamp:
The time when the FilingReview process (or user) decided that the
filing was
to be accepted or rejected (or, when it decided that the filing could
not be
reviewed at all)
We did not discuss this proposed value in today's conference calls,
but, to
be honest, I think there would've been little support for this value -
it is
more of a 'nice to know' than a 'need to know'.
But WAIT!!.... I think it might be a freebie:
If we agreed to make 'Authorized Timestamp' a member of *all* of our
messages...
..and also agreed to the functional definition I proposed above (or
something akin to it)...
...then the FilingReview_Callback message's 'Authorized Timestamp'
would
represent the 'FilingReviewedTimestamp'. We would have our bases
covered.
How's that sound?
- Shane Durham
_____
From: John M. Greacen [mailto:john@greacen.net]
Sent: Tuesday, October 11, 2005 11:09 AM
To: Electronic Court Filing Technical Committeee
Subject: [legalxml-courtfiling] Conference call continuation
Friends - I just touched base with Jim Cabral. To stay on our
timeline, we
must resolve the remaining issues today. Consequently, I have
scheduled a
further conference call for 4:00 pm Eastern, 1:00 pm Pacific time this
afternoon.
The call information remains the same:
Call in number 1-605-528-8855
Access code 2892164
We will resolve the remaining issues set forth below:
7. Whether we need a FilingAuthorized Timestamp - the time when a
user
approved (released) a filing to be sent to the filing review process
(Shane's recommendation).
8. Whether we need a FilingReceived Timestamp - the time when the
filing
review MDE received (lodged) a filing in addition to the
originalMessageReceipt date and time (Shane's recommendation).
9. Whether we need a FiledTimestamp - the legally effective date
assigned
to a filed document (Shane's recommendation).
10. Whether we need a DocketingReceived Timestamp - the time when the
court
record process receives a docketing (Shane's recommendation).
11. Whether we should adopt a model for person-organization
relationships
that is independent of the model used by GJXDM (Shane's
recommendation).
12 Whether we maintain the Service MDE (Shane believes that we
eliminated
it).
I hope that most of you will be able to participate.
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]