Eric,
I just realized I could be a little more helpful :-)
Here is for your extension.
You can easily add the rest - definitions of AffectedPartyID and
AdditionalData.
1. Create an xsd file standing for GreenFiling schema extension.
Let's call it GFiling-Extension.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://greenfiling/1.0"
xmlns:tns="http://greenfiling/1.0"
xmlns:ecf= .... other namespaces go here .....
targetNamespace="http://greenfiling/1.0"
elementFormDefault="qualified" >
<xsd:import .... a needed xsd is imported here ..... />
<xsd:import .... a needed xsd is imported here ..... />
<!-- Define your Document Metadata type -->
<xsd:complexType name="GreenDocumentMetadataType">
<xsd:annotation>
<xsd:documentation>DocumentMetadataType
extended.</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="ecf:DocumentMetadataType">
<xsd:sequence>
<xsd:element ref="AffectedPartyID"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element ref="AdditionalData"
minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- Use substitution groups to allow your DocumentMetadata
element to appear whenever ecf:DocumentMetadata may take place
-->
<xsd:element name="DocumentMetadata"
type="GreenDocumentMetadataType"
substitutionGroup="ecf:DocumentMetadata">
<xsd:annotation>
<xsd:documentation>A DocumentMetadata
occurrence.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- define your AffectedPartyID and AdditionalData in this file
as well -->
</xsd:schema>
2. Include your schema extension into your service schema
definition.
It would have namespace alias defined something like:
<xsd:schema .....
xmlns:greenfiling="http://greenfiling/1.0"
... >
....
<xsd:import namespace="http://greenfiling/1.0"
schemaLocation="./extension/GFiling-Extension.xsd"/>
...
3. Now, an XML message with your extension will validate to have the
following fragment
<RecordFilingRequest .....>
.....
<greenfiling:DocumentMetadata>
<j:RegisterActionDescriptionText/>
<ecf:FilingAttorneyID/>
<ecf:FilingPartyID/>
<ecf:RedactionRequiredIndicator>false</ecf:RedactionRequiredIndicator>
<greenfiling:AffectedPartyID />
<greenfiling:AdditionalData />
</greenfiling:DocumentMetadata>:
...
</RecordFilingRequest>
That's it.
-
Serguei
On 7/25/2012 2:27 PM, Serguei Mysko
wrote:
Eric,
You raised a number of issues.
I'd prefer to stick to the original ones until clear, step by
step.
We then could move on to the new points you brought in, like
FilingAttorney.
First, a general remark.
I think I understand your practical approach to get it done, a
good one.
True, it is not trivial with XML, schema, etc in a number of
places.
As for dealing with partners, here at Intresys, we have our part
of XML 'horror stories'.
From our experience most of the problems stem from the
difficulties to understand XML technologies, with namespace
probably taking #1 spot.
Not that much on ECF spec as per se.
You suggested changes to ECF schema, something in your opinion
would be useful across multiple implementations.
I can agree that the changes may work fine in your case.
I disagree that other implementations will necessarily benefit
from it.
On (1) - occurrences:
I found the following resource both illustrative and concise:
http://stackoverflow.com/questions/4821477/xml-schema-minoccurs-maxoccurs-default-values
Staying on the practical side.
There are/may be implementations that have no idea what JAXB is,
right?
JAXB works fine with default occurrences - one does not have to
explicitly specify default occurrence value.
JAXB works with unbounded value as well.
I did it myself with ECF v.4 schema.
I did have issues with the number of elements in
xsd\constraint\niem\fips* . I believe I had to create special
instructions for JAXB to deal with it or something.
I'd also suggest to look at XOM, dom4j and few other alternatives.
From what I hear, you could simplify your code when using XOM http://www.xom.nu/ as an example.
Don't know your specifics of course.
What would be a good approach to set maxoccurs value in ECF specs
schema?
Consider the number of filing documents example, a frequently
raised one.
Some Courts would have a single Lead doc, other would restrict the
total num of docs to less than 10 or so.
What should the schema have in its maxoccurs?
Shall we put there 100, 1000, more?
Either one would be an unnecessary and unjustified constraint to
be dealt by multiple implementations.
(Please note, that having unbounded value does not make JAXB to
allocate extra memory space)
On the other hand, there can be a single Parent document - no need
for unbounded value therefore.
But do we really want to enforce the maxoccurs of documents in the
schema?
Facing 100 Courts, do we envision a 100 possible scheme?
Or would we prefer the code to deal with it as per Court policy,
business rule?
XML schema is a poor means to define and enforce business rules.
Altogether.
I don't see how other implementations would benefit from your Part
1 proposal.
I can imagine it may resolve issues in your case.
On (2) : AffectedPartyID, AdditionalData
First, schema extension is not that scary and complicated as it
may seem.
Let's take a look.
With your proposal an XML fragment would look like:
....
<ecf:FilingPartyID>
<ecf:AffectedPartyID>
<!-- details about the AffectedPartyID go here -->
</ecf:AffectedPartyID>
...
With your extension in place it might look like:
<ecf:FilingPartyID>
<greenfiling:AffectedPartyID>
<!-- details about the AffectedPartyID go here -->
</greenfiling:AffectedPartyID>
...
With either schema:
- using JAXB, as you do, would just create the corresponding Java
object.
- using XOM, dom4j would extract value with a simple XPath
_expression_ or with a parent/child API.
That is, no extra efforts on either side, be it provider or
consumer.
Indeed, where would you see the extra development/processing
efforts when comparing the two XPath expressions:
//ecf:AffectedPartyID
//greenfiling:AffectedPartyID
?
With your proposal however we'd force other implementers to deal
with it.
With schema extension, GreenFiling would make a one time effort to
extend.
Secondly, as a design note.
Having AdditionalData as a bag of <String, String>
may appear as a costly design decision over time.
Here is why.
Step 1:
The code incorporates Map<String, String> (or
List<String, String>).
All components treat the property value as String.
Things work.
Step 2 (sometime later down the road):
You find out that some properties are actually complex structured
data.
You have no type info available to reflect a structure within a
String though.
You now have to introduce artificial agreements as for String
content: delimiters, or JSON, or XML, or come up with another
solution to address the structured nature.
You need to communicate, persist, search by property component,
etc. - all because of the new horizons from business folks.
Step 3:
Many places in your code now have "if" statements checking for
property name and applying different processing logic.
It is very hard to spot those places whenever changes in business
logic are due.
Step 4:
It is very hard to do the maintenance part from now on.
A better starting point would be to encapsulate property
processing into its own class, say MyProperty, giving us:
Map<String, MyProperty> instead.
In its extreme, the MyProperty could hold a Map<String,
String> inside if needed.
It would always have a interface shielding the internals.
Now, a structured property processing would be encapsulated within
MyProperty
My point here is that of a different implementer, who would feel
unhappy having AdditionalData in the schema as you suggested.
Who probably would email a different proposal to modify ECF
schema.
I am not criticizing, rather explaining why the proposal if
brought into ECF CommonTypes would immediately raise another
problem.
The design solution you have behind the proposal may work very
well in a number of cases, yours including.
It would not work in other cases, for the reasons mentioned above.
That's why, the compromise I see to address your problem and to
not affect other implementers, is to have schema extension.
Thanks,
-
Serguei
On 7/25/2012 5:27 AM, Eric Eastman
wrote:
ECF folks,
Thanks for considering this.
1. I thought that 1 was the default for maxoccurs and it
definitely is:
However, I'm using Java's JAXB for parsing/writing and that
seems to be treating "unbounded" as the default, at least some
of the time. I'll continue to research this, but I'd say that
being explicit is better than relying on defaults, especially
if that gets the correct behavior out of one of the major XML
tools.
Looking into the details of my other maxOccurs="unbounded"
gripes, I'm finding that they are declared explicitly that
way. For example, everything in PersonType and PersonNameType
in niem-core are unbounded. It seems reasonable to have a
list of aliases that a person has used, but that should be
a separate element (it's actually a separate case participant
with a role of "AKA" or "FKA" in most systems). Every system I
know about has a single main name for each person and that
name can contain only one last name.
2. I question the usefulness of having FilingAttorneyID
and FilingPartyID at the document level at all. That implies
that it is possible for a lead document to be filed by one
attorney on behalf of one party and a connected document on
the same filing be filed by a different attorney on behalf of
someone else, which I think is not the case. So those data
elements belong at the filing level rather than the document.
I also understand a pragmatic case against making that
change.
As for the AdditionalData, this is probably going to break
down along "Purist" vs. "Git r done" lines. I acknowledge the
logical argument that Serguei is making. Let me make the
pragmatic one:
I'm dealing with a partner who doesn't have the greatest
level of XML sophistication. Creating an extension is not a
good solution for us politically. I'm convincing them to use
ECF for my own (somewhat selfish) reasons.
Think about from the perspective of my partner in this
interface; he just wants to get his job done quickly. "So
you're telling me that in these dozens of namespaces and
schemas and a thousand data types that we already have, and
after we have filled in a dozen values that we don't really
need so that it validates, we still have to create our own
schema just to store the ServiceType?!?! Why didn't we just
create our own schema to begin with?"
This guy is exactly the sort we need to be able to make a
compelling case to if we want ECF adopted broadly. If
something as basic and easily foreseeable as this requires an
extension then every ECF deployment will need an extension and
we should include a sample extension shipped with the standard
and be clear from the beginning.
One of the first people I ever build client-server
applications with always included "Extra 1", "Extra 2" and
"Extra 3" fields on each screen, because, if you don't, users
start shoehorning the data they need into the existing fields.
In the end this is about humility, realizing that I'm not so
smart that I can anticipate everything.
Thanks for your consideration,
Eric
On Tue, Jul 24, 2012 at 3:43 PM,
Serguei Mysko <sergueim@intresys.com>
wrote:
Hi,
I see two aspects in the proposal:
1. Cardinality: maxOccurs="1";
2. New elements: AffectedPartyID, AdditionalData
On (1):
Schema default value for occurrence is 1.
Therefore, as an example,
<xsd:element ref="ParentDocumentReference"
minOccurs="0"/> as in the spec
and
<xsd:element ref="ParentDocumentReference"
minOccurs="0" maxOccurs="1" /> as in the
proposal
come to the very same result.
As a side remark on the subject.
I believe that in practice cardinality is quite
often regulated by Court policy/business rules
rather than schema spec.
A Court, for instance, may accept no more than 4
Defendants, while another Court would impose no such
constraints.
On (2):
Apparently the purpose of the AffectedPartyID
element is to have a list of other, somehow related
parties.
Looking from the spec side (its Common Types).
Is it possible to not have other somehow related
(affected in a way) parties?
- Yes.
Is it possible to not have FilingParty?
- No.
The purpose of the AdditionalData is to get
a typeless (anything goes into String) bag of
name/value pairs.
Looking from the spec side.
Will all or most of the implementers need a bag of
typeless properties.
- A number of implementations will need a provision
to specify additional properties, each with own way.
This however does not belong to Common Types.
Because we do not introduce new common type, rather
a collection of generic (strings) elements.
A better solution for (2) would be to create an
extension.
That would resolve the problem at hand while not
affecting other implementations that do not face the
same problem.
Thank you.
-
Serguei Mysko
Intresys
On 7/24/2012 7:26 AM, James E Cabral wrote:
ECF
TC:
Here
is a proposed patch to ECF 4.01 from Green
Filing. Since these add content and
constraints, unless there is an immediate
need to get these into ECF 4.01, let’s
consider these for ECF 4.1.
Jim
Cabral
MTG
Management Consultants, L.L.C.
www.mtgmc.com
(206)
442-5010 Phone
(502)
509-4532 Mobile
Helping
our clients make a difference in the
lives of the people they serve.
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:
Eric Eastman [mailto:eric@greenfiling.com]
Sent: Tuesday, July 24, 2012 10:21
AM
To: James E Cabral
Cc: George Knecht
Subject: Proposed patch to ECF 4.0
Jim,
As you know, we have
created an EFSP (FilingAssemblyMDE) for
the state of Utah. This currently uses a
LegalXML 1.1 (bastardized) interface to
the courts. We are in the final stages of
providing a bulk filing interface to one
of our existing customers using ECF 4.0.1
and have felt it necessary to extend the
information in the DocumentMetadata
element. Please consider the following
changes to the ECF-4.0-CommonTypes.xsd
file for possible inclusion in a future
release of ECF. Also let me know if there
is a better way of approaching this
problem that I missed. I think the
annotations in the xsd code below spell
out what I'm trying to do. I'd be happy to
talk about it if/when you have time.
Additionally, for a
future release, there are many places
where adding a maxOccurs="1" would
make parsing the documents easier. The
default, at least as JAXB has implemented
it is "unbounded".
[Edited section.
Changes in bold.]
<xsd:complexType
name="DocumentMetadataType">
<xsd:annotation>
<xsd:documentation>Document
descriptors (title, type description,
etc.) for the Document. This is
meant to include all the information about
the document that is needed to index it
into the Case
Management System and enter it into the
Document Management
System.</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension
base="s:MetadataType">
<xsd:sequence>
<xsd:element
ref="j:RegisterActionDescriptionText"
minOccurs="0" maxOccurs="1" />
<xsd:element
ref="ParentDocumentReference"
minOccurs="0" maxOccurs="1" />
<xsd:element
ref="PriorRelatedDocumentID" minOccurs="0"
maxOccurs="1" />
<xsd:element ref="FilingAttorneyID"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="FilingPartyID"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="AffectedPartyID"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element
ref="SpecialHandlingInstructions"
minOccurs="0" maxOccurs="1" />
<xsd:element
ref="RedactionRequiredIndicator"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="AdditionalData"
maxOccurs="unbounded" minOccurs="0" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="AffectedPartyID"
type="nc:IdentificationType">
<xsd:annotation>
<xsd:documentation>ID recognized
by the court as being unique within this
case,and used to identify a party who will
be affected by filing this document (eg.
which party was served by a return of
service).</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType
name="AdditionalDataType">
<xsd:attribute name="name"
type="xsd:string"></xsd:attribute>
<xsd:attribute name="value"
type="xsd:string"></xsd:attribute>
</xsd:complexType>
<xsd:element name="AdditionalData"
type="AdditionalDataType">
<xsd:annotation>
<xsd:documentation>Any
additional information that needs to be
passed along with the document. This might
include the method of service for a Return
of Service or the amount of a
Judgement.</xsd:documentation>
</xsd:annotation>
</xsd:element>
--
Eric Dimick Eastman
Green Filing, LLC
--
Eric Dimick Eastman
Green Filing, LLC
|