Also
for what it's worth:
1) If
you want to "dumb down" the rendition (display) of the DTD, I'm betting there is
someone on the list that could write an XSLT transformation that could provide a
rendition of the DTD that only had required elements and attributes. This would
eliminate the need for a separate DTD for reference purposes.
2) I
disagree when people undervalue the human readability aspects of XML. I believe
this to be a strength and a major reason for acceptance of XML as a standard for
developing standards. It's true that the machines don't care, but I care when I
have to design, document, test, debug and gain approval from non-technical or
non-XML literate associates and customers.
3) "X"
is for extensible. I do not believe that a "standard" such as the Court Filing
DTD is or must be a total solution for every implementation (ideal, but not practical).
4)
Required elements and attributes must be carefully evaluated because they must
be understood by all implementations.
5) If
an implementation extends the standard, the extensions should be easily
identifiable by other implementations and well documented within the DTD or Schema.
6) I
agree with Todd. The problems that you list, imho, would be easily solved
with a Schema.
gary
-----Original
Message----- From: Dallas Powell
[mailto:dpowell@tybera.com] Sent: Wednesday, September 11, 2002 6:02
PM To: legalxml-courtfiling@lists.oasis-open.org Subject:
Re: [legalxml-courtfiling] Salt Lake minutes
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
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.
*****************************************************************************
|