[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] Proper Use of SendingLocationMDE
Gary, You’re right – ErrorCode is part of the machine-readable policy.
Your example looks correct. I notice that you also define id’s for each
ErrorCode value. Is that how you are including support for severity? Jim Cabral James
E. Cabral Jr. 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: Graham, Gary
[mailto:GGraham@courts.az.gov] Jim, thank you for your prompt reply. As you say in your reply, ErrorCode “is based on
PolicyDefinedErrorCodeTypeText which indicates that the court should define the
error code list in Court Policy.” I have been under the assumption that the
error codes should be defined in Machine-Readbale policy rather than
Human-Readable; more specifically, in <RunTimePolicyParameters> in the
event that the ‘glossary’ of error codes may expand over time. Below is a
fragment from the CourtPolicyResponseMessage that illustrates my thinking
(note: this also includes an idea on how error severity may be communicated in
the id attribute):
<RuntimePolicyParameters>
<PublicKeyInformation>
<digsig:KeyInfo>
<digsig:KeyName>CourtPublicKey</digsig:KeyName>
</digsig:KeyInfo>
</PublicKeyInformation>
<CoreCodelist>
<ElementName>common:CaseTypeCode</ElementName>
<AllowedCodeValue>
<ValueText>CR</ValueText>
<DisplayText>Criminal</DisplayText>
<EffectiveDate>1967-08-13</EffectiveDate>
</AllowedCodeValue>
</CoreCodelist>
<CoreCodelist>
<ElementName>common:ErrorCode</ElementName>
<AllowedCodeValue>
<ValueText id="NoError:0">0</ValueText>
<DisplayText>No
Error</DisplayText>
<EffectiveDate>1967-08-13</EffectiveDate>
</AllowedCodeValue>
<AllowedCodeValue>
<ValueText id="Warning:100">100</ValueText>
<DisplayText>No
Policy Available</DisplayText>
<EffectiveDate>1967-08-13</EffectiveDate>
</AllowedCodeValue>
<AllowedCodeValue>
<ValueText id="Fatal:101">101</ValueText>
<DisplayText>Policy
Expired</DisplayText>
<EffectiveDate>1967-08-13</EffectiveDate>
</AllowedCodeValue>
</CoreCodelist>
</RuntimePolicyParameters> In an actual implementation, I suspect there will be many more
possible Error Codes. Am I on the right track here or completely off in the hinterlands? Gary Graham Arizona Supreme Court -----Original Message----- Gary, I’ve attached answers to your
questions below. Jim Cabral James E. Cabral Jr. 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: Graham, Gary [mailto:GGraham@courts.az.gov]
Thank you for the clarification;
as a result, I will want to amend the Message examples I provided previoulsy. I am now focusing on the Ploicy
messages and have a few additional questions regarding Policy. Policy – The ECF 3.01
specification, section 2.4.4 ‘Court Specific Code Lists’, says a “court SHOULD
provide values for each of the following code lists…” Included in the list of
code lists is <ErrorCode>. I presume this would be used to by the Filing
Review MDE to inform the Filing Assembly MDE of the Error Codes that it may
expect to receive, and include a textual description for each code. I am not aware
of any standard for these codes other than ‘zero’ (0) which means no error. I
further presume that these <ErrorCode>s would be communicated to the
Filing Review MDE in the CourtPolicyResponseMessage. However, the XML does not
appear to contain elements for returning the <ErrorCode> list (there are
elements to communicate whether or not an error occurred in the GetPolicy
operation). Furthermore, I cannot find any XSD for the <ErrorCode>
list. Are there standard codes? Is there an XSD for Error
Codes? Where in the message do these codes go?
<CourtExtension>? Or <CoreCodeList>? What should the value be for
<ElementName> within <CoreCodeList>? (in the XML Example, for Case
Type, the value is ‘common:CaseTypeCode’ – in the common folder I find an
ECF-3.0-CaseType.xsd, but not a CaseTypeCode.xsd) How is Error Severity
communicated? All messages (including
CourtPolicyResponseMessage) include the Error element which includes ErrorCode
and ErrorText elements. The ErrorCode element is based on PolicyDefinedCodeTextType which indicates that the court should define the
code list in Court Policy. The definition for ErrorCode says that 0
is reserved for “no error” but this is not enforced in schema.
There is no built-in mechanism in ECF for communicating error severity but, if
a court needed it, the court could associate certain severity levels with
certain codes (e.g. errors 100-200 are minor, error 200-300 are severe, etc.) Or, is there no need to send a
full Error Code set from the Filing Review MDE to the Filing Assembly MDE
because only the ‘current’ error(s) (if any, else 0 – No Error) is returned,
and the Filing Assembly MDE can just display the returned DisplayText to the
user? Right – there is no need to send a full Error
Code set since it is defined in Court Policy. The
ECF-3.0-CourtPolicyResponseMessage.xsd permits zero to unlimited message:Error
elements. When the called operation returns multiple error codes, is there a
standard or a convention on how this should be done? (i.e. in the order the
errors occurred, or most significant to least significant, etc.) There is no current standard or convention
for this. Is it important enough that we need to add one? How many Revision Numbers? ECF 3.01 states: “The court MUST
have only one active, authoritative version of its human-readable,
development-time, and run-time policies at a given time.” The term “only one”
suggests that the combined set of Human-readable policy and Machine-readable
policy is considered a single policy. However, ECF 3.01 also states: “The
court’s human-readable and machine-readable court policies MUST both have a
version numbering method associated with them.” This seems to suggest two
separate version numbers as “both” “MUST” “have a version numbering method”;
not “both MUST have a single version numbering …”. However, the
ECF-3.0-CourtPolicyResponseMessage.xsd only contains one Policy version element
(i.e. policyresponse:PolicyVersionID). If there are two version numbers, which
(Human or Machine-Readable) goes into policyresponse:PolicyVersionID, and where
does the other go? The human-readable and machine-readable
policies are versioned separately. The CourtPolicyResponseMessage only
returns the machine-readable version and therefore, only includes one Policy
version number. We do not define a structure for human-readable policies
but it must include the version somewhere in the human-readable policy. Also note that the XSD definition
for policyresponse:PolicyVersionID may be incorrect. It states that it’s “up to
the court to define the format for this” (the version number); however, it
appears that ECF 3.01 section 2.4 defines the format of version as
MAJOR.MINOR.PATCH (however, it’s specified as a SHOULD comply, not a MUST). I think this is ok. We say the court
MUST define a format it and suggest a recommended format but don’t require them
to use it. Gary Graham -----Original Message----- Gary, The definitions of
message:SendingMDEProfileCode and message:ReceivingMDEProfileCode still
referred to “message profiles” which were renamed “service interaction
profiles” in ECF 3.01 to bring us into conformance with the OASIS SOA Reference
Model. I have now updated the definitions. The profile codes are defined
ECF 3.0 Service Interaction Profiles, e.g. the ECF 3.0 Web Services Service
Interaction Profile uses the following code: urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:WebServicesMessaging-1.0. Regarding the
SendingMDELocationID, the complete definition is “Location for the MDE to which
asynchronous and service messages can be sent. This unique location is
self-assigned by the MDE.” This definition is consistent with its
use. In short, the MDE receiving a message already knows its own ID – it
just needs to receive the ID of the sending MDE. In your example: FilingReview operation 1. FilingAssemblyMDE
sends a CoreFilingMessage with SendingMDELocationID set to the
FilingAssemblyMDE’s ID. 2. FilingReviewMDE
sends a MessageReceiptMessage (synchronous response) with SendingMDELocaitonID
set to the FilingReviewMDE’s ID. NotifyFilingReviewComplete
operation (after review and docketing is complete): 3. FilingReviewMDE
sends a ReviewFilingCallbackMessage (asynchronous response) with
SendingMDELocaitonID set to the FilingReviewMDE’s ID. Does this clarify? Jim Cabral James E. Cabral Jr. 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: Graham, Gary [mailto:GGraham@courts.az.gov]
I’m having some trouble trying to determine
the proper use of the elements <message:SendingMDELocationID> and <message:SendingMDEProfileCode>, specifically in the
CourtPolicyResponseMessage, but generally, in any message. From the XSD, you can find the following
definitions: <message:SendingMDELocationID> - Location
for the MDE to which asynchronous and service messages can be sent. This unique
location is self-assigned by the MDE. <message:SendingMDEProfileCode> - Code
identifying the message profile being used by the sending filing assembly MDE.
This list should be extensible to accommodate future messaging profiles. Each
code value is specified within the message profile approved for use with ECF. The Sample XML simply shows ‘MDEID’ as the example for
Location, and ‘MESSAGINGPROFILEID’ for the Profile. So here’s my question: In the CourtPolicyResponseMessage
which is being returned to the Filing Assembly MDE from the Filing Review MDE,
should the <message:SendingMDELocationID>
identify
the Filing Assembly MDE and not the Filing Review MDE? On the Sequence Diagram from the specification
document (i.e. ecf-v3.01-spec-wd02.doc, page 23) the response is shown as a
dashed line which indicates a synchronous response. However, the definition of <message:SendingMDELocationID> addresses
‘asynchronous and service messages’; it is neither. Is this just an error in
the definition or am I missing something? The definition for <message:SendingMDEProfileCode> talks about a
“message profile”. What is a “message profile”, and where is this defined? It
also mentions a “list”. Where is this list of message profiles? How are
practitioners using this element? Also, it says it’s the profile “used by the
sending filing assembly MDE”; so if the answer to the first Location question
is Filing Review MDE and not Filing Assembly MDE as I suggest, then please
explain. Thank you in advance for your considered
response, Gary Graham Arizona Supreme Court |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]