OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-courtfiling message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [legalxml-courtfiling] Timestamps


Title: RE: [legalxml-courtfiling] Timestamps

Robert,

>> The "creation" date time stamp...
...is what the Court here is using as determinative of the filing date, as requested and agreed upon by the Bar

Thanks for the insights into your courts' use of LegalXML's CreationTime.
This is the first occasion I have heard of a court functionally using that value.
Previously, I have only seen it used as a kind of debugging/tracing/warm-fuzzy mechanism.



All,

The value that Robert is describing corresponds to what I previously identified as:

AssemblyTimestamp- The time when the data was put together into an XML message.
In our last conference call, I think we concluded that we would not include this value in our messages.

Shall we reconsider that decision?
- It would be a very minor change to the spec.
- I feel it is a useful value that many developers and administrators would expect to be present.
- Robert has identified it as a value that some courts are using functionally.
- Robert also reminded us that it would be consistent (compatible) with the LegalXML 1.x spec's 'CreationTime'.

And, just for clarification, let's keep in mind, AssemblyTimestamp is functionally distinct from other values we have discussed:

AuthorizedTimestamp - When a user or process released the data to be transmitted.
We have agreed to add this to our BaseMessage.

ReceivedTimestamp - When the message was received by the recipient MDE.

SentTimestamp - When the message was sent by the sending MDE.
I do not advocate expressing this value in our messages.
Primarily for the reason that Robert noted: it would require that the message be changed everytime we send it.

- Shane Durham
LexisNexis



-----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
 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]