|
for what its worth
Having participated in the GCAC
interoperability test at the very end (as both an EFM and EFSP), there
were a few things that we struggled with. Because there was more than one
place to introduce actors, there was uncertainty among the vendors about where
to put the information. Also from our memory there seemed to be
some elements that did not directly map to fields we needed
to loaded and updated the SUSTAIN CMS so we made some interpretations
specific to a court.
One of our specific disappointments about the DTD
is that you don't know what type of filing you are receiving until you get to
the lead document.
In speaking with Todd at the CA AOC CEFTS meeting
held in June 2002, my interpretation of a discussion that I had with him
was that there are some areas of the DTD that can work for all courts, and there
are areas where courts need specific information. To encompass every need
for all courts may not be feasible within a DTD, where as schema offers more
options. Perhaps that may give more insight to what a DTD Lite might
mean.
Also, in the interoperability test, since we were
supporting Digital Signatures and no one else could support it, we had
to ignore that portion of the DTD and not include those components in our
transmissions. We did not specifically look at all the elements that were
or were not used. That may be another motive for a DTD
Lite?
Dallas
----- Original Message -----
Sent: Tuesday, September 10, 2002 9:22
AM
Subject: RE: [legalxml-courtfiling] Salt
Lake minutes
I'd like to chime in
with my concerns about the idea of a "DTD Lite."
The Court Document
drafting committee has raised the question of "ease of use of" and "ease of
learning" a specification as reasons for such a construct (I don't have a
specific location I'm pointing to in the draft CD 1.1, but recall it's being
asserted there). I admit to having not grasped the rationale for this.
I would not expect a
non-technical, business expert to learn about the functionality, scope, and
details of a specification by reading a DTD or Schema itself. Those of us
advocating for standards, application developers, EFSPs, and others will need
to provide written explanations, presentations, diagrams, and so forth, to
promote such learning.
If the "Lite" version
is necessary to "dumb down" the specification for use by certain application
developers, I think there might be a problem with the developers. I do not
understand what economy there would be in stripping some amount of ASCII text
from a specification in order to "simplify" it, when that economy is
contrasted with the potential costs from reconciling the kinds of errors Don
has suggested might occur. Perhaps someone can explain this and convince me
otherwise?
I feel it is a
substantial and critical task of the Technical Committee to maintain its DTDs
and Schemas entire and intact, to ensure they are accessible, reliable, valid,
etc. If a particular application developer, court, etc., wants to build for
local use a "Lite" version of the specification, they should be free to do so,
but at their own risk. I do not think the Technical Committee should have
"Heavy" and "Lite" versions of its products, particularly when those wanting
the "Lite" version need only omit the elements they don't find relevant to
their own uses. It should be up to them to keep their mini-specs valid against
the official full-sized specs, which the Technical Committee would be
responsible for.
I admit to ignorance
regarding technical factors that might have motivated Todd or others to desire
"Lite DTDs." I am willing to learn more about that, but need convincing on why
it would be the responsibility of the Technical Committee to provide and
maintain those variations. If you can't convince me on technical grounds due
to my lack of such expertise, you could try persuading me by precedent - how,
why, and with what effects (positive and negative) have other comparable
specifications been developed and maintained in "full" and "lite"
versions?
Regards,
Roger
Roger
Winters
Electronic Court
Records Manager
King
County
Department of Judicial Administration
516 Third Avenue,
E-609 MS: KCC-JA-0609
Seattle, Washington
98104
V: (206) 296-7838 F:
(206) 296-0906
roger.winters@metrokc.gov
-----Original
Message-----
From: Bergeron,
Donald L. (LNG) [mailto:Donald.Bergeron@lexisnexis.com]
Sent: Tuesday, September 10, 2002 5:39
AM
To: 'Chambers, Rolly';
Bergeron, Donald L. (LNG); John Messing;
legalxml-courtfiling@lists.oasis-open.org
Subject: RE: [legalxml-courtfiling] Salt
Lake minutes
I agree
with most of your points especially having this subset as a single OASIS
LegalXML Standard or as a section of one. My concern is jurisdictional
subsetting by individual courts could create an improper subsets. If you
carry this out over a wider group jurisdictions the probability of error is
higher. My further point is, at this time there is no straight forward
software way of confirming that a subset is proper to assist the community.
Subset DTDs become an object that must be change controlled and managed. The
skill set to subset DTDs is often not present in a software
developer therefore you may have more than one person in the loop with
the attendant human communication and human error.
Many organizations
that use more than one dtd (subset/superset) in a process-flow generate
the DTDs from a single master source object.
There may be an
impact on the EFPs, which would then have to manage the DTD Subsets from many
Courts. This will induce more overhead on their part as they cross
jurisdictions.
I have found that a
metadata approach such as Court Policy can be made deterministic over time and
has a lower human error rate. Additionally, if you use two ways of providing
additional constraints (subsetting and Court Policy) two negative results can
occur. The two constraint systems can have effects at the intersection that
are subtle, hard to reveal plus hard to diagnose and remove when found.
The second effect of this is as you optimize the Court Policy Constraint
handler you only get part of the benefit that you might otherwise
get.
-----Original
Message-----
From:
Chambers, Rolly [mailto:rlchambers@smithcurrie.com]
Sent: Monday, September 09, 2002 10:55
PM
To: Bergeron, Donald L.
(LNG); John Messing; legalxml-courtfiling@lists.oasis-open.org
Subject: RE: [legalxml-courtfiling]
Salt Lake minutes
I'm assuming that "subsetting the DTD" refers to the
proposal to provide a simplified CD 1.1 DTD or CD 1.1
"lite."
You probably are aware that the Todd Vincent who
expressed the "over-inclusive but optional" approach to developing the Court
Filing 1.1 DTD is the same Todd Vincent who, after working with the CF 1.1
DTD in the GCAC interoperability pilot, wrote the "Lessons Learned"
document. That paper suggests that "It may, therefore, make sense for
individual jurisdictions to create a 'backwards-compatible subset' of the
Court Filing DTD for specific purposes and requirements."
For clarification, is your concern that "subsetting"
the CD 1.1 DTD should not be addressed in the CD 1.1 spec itself but should
be left to individual jurisdictions to address via court policy standards?
It sounds like the worry is that subsetting the CD 1.1 DTD as part of the
Court Document specification may intrude upon and get crosswise with court
policy standards.
Or is your concern broader - that there should never
be subsetting of the CD 1.1 DTD either by individual jurisdictions or by the
CD 1.1 spec?
As far as the Court Document proposal goes, the aim
is to offer a single simplified CD 1.1 DTD (not multiple subsets) as
something purely optional and perhaps easier to get started with than taking
on the full CD 1.1 DTD. The object is to trim from the full CD 1.1 DTD
elements and attributes that are optional and not frequently used in most
court documents, such as the "notarization," "personIdentification" and
"organizationIdentification" elements, some of the optional attributes, etc.
The assumption is that it might be easier to start learning with a simpler
subset of the full DTD. The tradeoff is that a simplified DTD would be
useful for validating basic, "plain vanilla" XML court documents but not
those requiring the richer markup in the full DTD. Of course, maybe you are
suggesting that simplifying the CD 1.1 DTD won't make it any easier to learn
and is not worth pursuing.
Finally, are you concerned that some
features of the proposed simplified CD 1.1 DTD make it an improper subset of
the full DTD? If there are some specific "bloopers" in the simplified Court
Document DTD, please let us know what they are. I'm much more receptive to
correction from my friends than from strangers.
Thanks for sharing the
comments.
-----Original
Message-----
From:
Bergeron, Donald L. (LNG)
Sent: Mon 9/9/2002
7:56
AM
To: 'John Messing';
legalxml-courtfiling@lists.oasis-open.org
Cc: Bergeron, Donald L. (LNG)
Subject: RE:
[legalxml-courtfiling] Salt Lake minutes
Thank
you John for your posting. I think that it will go far in
increasing
understanding.
On the specific issue of subsetting
the DTD, I have a concern. The overall
LegalXML model as expressed by
Todd Vincent and reiterated many times is
that this dtd is
over-inclusive but optional to cover as many conditions as
practical
and to not place unnecessary constrains on any jurisdiction using
this
dtd.
If there is a way of always getting a proper subset of a dtd,
and validating
that condition well we may use it. Some of the
approaches that you mention
can provide part of this service. However,
the part that it is always a
proper subset is at risk as humans modify
the parameter entities on which
most of these are based. Only one
method, the Architectural Forms approach
has the concepts needed. This
approach is not present in most commercial
software nor is it likely to
as it has regretfully fallen out of favor. This
may be remedeiated W3C
Schema World, although I am not sure of this. This
constraint should be
looked upon as a requirement for CF 2.0. During the
implementation, if
the requirement can not be met we can address it as a
change control to
the requirements.
Beyond this, the constraints of the set has
always been a goal and
requirement of the court policy standards. This
is only part of the policy
requirements, but it is a part. One should
think setting constraints that
are jurisdiction specific in a way that
is localized in one place. This
allows the person developing the
constraints to look at the full constraint
set so that it can be
balanced and tuned. When you spread the validation to
two functions
that are invisible to one another you increase the very human
risk of
getting it wrong.
This should be further studied during the
research needed to implement the
requirements of court policy
1.0.
Regards,
Don Bergeron - Chair - Court Policy
Sub-committee
|