RE: [legalxml-courtfiling] Timestamps

[Shane.Durham@lexisnexis.com]

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