[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] Common data elements across messages
I think that making FilingId a member of every non-query message would be a bit short-sighted.Though I am *usually* a stickler for working within our explicit requirements, the practical side of me must speak out from time-to-time as well...It is not difficult to foresee many interactions between MDEs that will not refer to a filing, and therefore not have a filingId.1) Query interactions are an immediate example from our current requirements.Not every query needs to refer to a filingId.2) The 'docketing process' might also be without filingId, if (as I have suggested) we were to consider a docketing as a stand-alone concept. Just consider a scenario when we might want to record data that did not originate from an electronic filing process.3) Going just a little bit outside of our current requirements, a 'filer registration' process would likely be without filingid.I have been involved in at least two systems that explicitly implemented a registration process. It is a very real process we will eventually need to develop.I suggest that we indicate filingId as an explicit member of those messages that are filing related. We should *not* attempt to make it a member of *all* blue non-query messages.
I *might* be willing to say this is more-or-less the same thing as 'The MDE from which the message was generated' and *might* be just as easily called 'FromMde'.However, not every message that is assembled and transmitted will come from what-we-would-consider to be an MDE. Queries continue to be a decent example of this - a valid query message can be assembled and transmitted *to* an MDE, though the caller, itself, might not be able to receive any blue messages and is not, itself, an MDE.Consider a stand-alone kiosk that is designed to interact with a CourtRecord MDE's query functions. The kiosk, itself, is not really an MDE. It just interacts with an MDE. Nevertheless, something in our blue messages should permit the kiosk to express its identity in some way that permits the CourtRecord MDE to authenticate the kiosk (to the satisfaction of the implementers).
I think we should use a different term for this value than SubmissionDateTime.Lots of folks prefer think of 'SubmissionDateTime' as 'the legal time a filing is considered as transmitted to the court'.In this context, I think we mean something quite a bit less weighty (and, perhaps, less open to interpretation).For each blue message, we would like a timestamp representing when the message was assembled and its transmission initiated.Note that this the timestamp value does not (could not) indicate that the message was received, nor does it necessarily have any legal meaning (as 'submissionDateTime' might). It is merely a courtesy/systemAdmin value that *could* be given more functional meaning, if the implementation wants to do so.I suggest we just call it 'MessageDateTime'.Note1: Some developers might fuss about my definition of 'MessageDateTime'. They *might* nit-pick that the timestamp of when a message was assembled and when a message was transmitted could be very distinct values, and, the distinction could be important to some implementers. I think a single timestamp is generally sufficient for our purposes but I could be easily coaxed into adjusting our standard such that it supports TWO timestamps, messageSentTime and messageAssembledTime, where 'assembledTime' would be an optional value.Note2: Functionally, we of course need a timestamp to indicate when a message was received. For DataUpdate interactions, (and EventNotification and Report interactions) , this functional value would be the 'MessageTimestamp' expressed within the 'MessageReceipt' message. For Queries, the received timestamp is essentially the 'MessageTimestamp' expressed in the query response (or QueryFault). Or, I suppose all of these response variations could contain an element to explicitly indicate when the initiating message was received.
Of course, we haven't yet defined any practical pattern for how users could be expressed such that they are consistently meaningful between a system's MDEs. But, in theory, this message property exists and should be expressible. We need to work on it.
This would seemingly be a 'courtesy' value.The MDEs will often (if not always) have distinct addresses in the overall system such that that a message is directed to a specific MDE at a specific address, and any information embedded within the message, to indicate the intended 'to Mde' is somewhat redundant.But, when you start to talk about issues of security, message validation, authentication, etc. we can get some good warm fuzzies to clearly see that a message received by my 'xx MDE' was, indeed, explicitly intended for my 'xx MDE'.
DataUpdate (i.e. Transactional) interactions, can make the most use of this value in order to identify the MDE to which a callback function should be directed. Likewise for 'Report Interactions', if/when we decide to implement such processes.
Query interactions (and EventNotification interactions) would not absolutely need this value, since their responses are synchronous - directly and immediately returned to the caller. However, even in a query scenario, the 'reply to MDE' might be useful for system adminstrators' authentication logic or in the event of an unusual interaction failure.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]