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
|