Thank you, Gary, for
a response to my questions that helped me understand a bit more about the
reasons for wanting a lighter tool to work with than we'd have with a
specification that includes everything everyone might possibly think
of.
I agree with you that
a great advantage of XML is that recognizable words are used in the tags and
non-technical people can see how their business concerns are included. There
could be many ways to get buy-in from such folks: a) focus on specific
portions of the specification they're likely to be interested in, b) organize
specifications so the required elements and attributes appear first, or at
least separately, or show up in different colors or fonts to distinguish them
from the optional, or c) build presentations appropriate for the audience and
draw from the specifications those examples that will help them understand
(and approve) the work.
I'm glad to read that
you and Dallas believe that Schema will make it much easier to handle many
issues, because we have said we are moving to Schema for the Court Filing
specification, in "2.0" and subsequent versions. I haven't heard anyone
advocate for sticking with DTDs, except to ensure ongoing support for
implementations built based on them.
Notes on your 6
points:
1)
It's great if someone
actually would create the XSLT transformation to do what you describe. (I'm
not sure that affects the need to have the specification, whatever it
contains, maintained intact and entire by the Technical Committee, and I don't
think that makes the Technical Committee responsible for maintaining all such
transformations as derivative specifications. Please correct me if I'm
wrong.)
2)
I agree on the human
readability advantages XML gives us and I hope our specifications are written
to support the kind of work you and others will be doing with them. The way to
make that happen is for those who understand the needs of those doing design,
testing, debugging, and approval-getting to participate in drafting the
specifications. Look at what we did when authoring our first specification:
Court Filing 1.0 and 1.1 were largely worked out by Marty Halvorson from the
New
Mexico courts, and I (not a
technical expert) edited the work by checking for typos and other nit-picky
details and by rewriting narrative so it would be more easily understood by
technical and non-technical readers. We really didn't have much direct
participation in the authoring work by someone with insight into how design,
testing, debugging, etc., would be affected by how the specification is
organized, written, and presented. The specification was reviewed by many
people and adopted by the TC, which is its real owner, but there was no one
who stepped up and said, "I can reorganize this so it would be better for
designers, etc." I'm sure we would have welcomed such a volunteer into the
effort (assuming it wasn't last-minute). Neither Marty nor I (nor others who
gave input) pretended to represent every perspective that might relate to
using the specification. We just did the best we could, with Mary asking,
again and again, for input, help finding flaws and problems, ideas for
improvement, and volunteer time from whoever would and could help. I fear the
same process is under way with Court Document 1.1, where the drafters perceive
and are dealing with needs and issues they understand or believe they can
address, but unless we open the specification development to bring in other
perspectives to shape the final product, the specification we adopt will be
subject to similar criticism. We simply need more worker bees bringing time
and competencies into the specification development process. We have plenty of
reviewer bees ready to ask questions, critique, and, ultimately, vote to
approve.
3)
Absolutely right! The
genius of XML is its extensibility. Court Filing 1.1 has explicit direction
about how we are to set up any extensions of it. I believe our specifications
may continue to unfold with increasingly detailed and sophisticated content as
they are adopted for use in more and more subject matter areas. That is why we
need close and professional attention to editing, version control,
repositories, and other such dry, but necessary stuff. Personally, I hope that
Court related specifications can be extended to cover all of the business of
courts. I will resist extending those specifications to include things like
chemistry, music, basket-weaving, or other non-court subjects. I think it is a
good thing if we try to comprehend court business elements and attributes
(over time), so XML will serve throughout our court organizations, which are
not simple things.
4)
Yes, the required
elements and attributes must be understood and endorsed by all. How do we make
sure everyone knows what is required? Education is one way. Presentation
within the specification might be another. Attention given by those with
authority in our systems will be another. We all have to participate in making
them stand out and work for everyone, since we make them requirements on
everyone.
5)
We could use help in
ensuring extensions are handled so they work as you state. Look at Court
Filing 1.1 on how to create and implement extensions. Is that the correct way
to approach them? Can you or someone else propose improvements or even a
completely different way of handling extensions? That's what we
need.
6)
I don't pretend to
understand Schema technically, but I know lots of our people have praised it
and said it offers answers for many of our needs. I frankly don't understand
why we're not pouring energy and effort into developing the Schemas everyone
wants and needs. Maybe it's because we don't have enough worker bees able and
willing to give time and talent to the efforts. We are still an all-volunteer
army with only a few out on the front lines.
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:
Poindexter, Gary W [mailto:gpoindexter@kpmg.com]
Sent: Wednesday, September 11, 2002 9:02
PM
To: Dallas Powell;
legalxml-courtfiling@lists.oasis-open.org
Subject: RE: [legalxml-courtfiling] Salt
Lake minutes
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.