RE: [legalxml-econtracts] Pruning XHTML2 for eContracts - draft 2

["Mary McRae" <mary@office-xml.com>]

Now that I've introduced myself, I'd like to comment, and then retreat to
the back of the room in anticipation of being drummed out of the committee
and banished from the list.

1. I do not believe that adopting XHTML is the right approach (but if it is
to be used, it should definitely be pruned according to Jason's proposal). I
strongly believe in using XML for its intended purpose - identifying
content. Robust systems can be built on explicit markup where generic markup
models fail. I've read through some of the previous documents and I
understand the difficulty in agreeing on common vocabulary, but this is
always the biggest obstacle faced by any DTD design team. Even within a
200-person company, users in one department will use a specific label to
identify something and users in another department will have a different
label. Is it a cup or a mug? A dish or a plate? The reality is that the
vocabulary we choose should not matter, since the goal should be to keep the
XML behind-the-scenes where it belongs - full access to those designing the
systems but limited exposure to the end user. I do not expect to see legal
secretaries, lawyers, and everyone in between working with "tags." They
don't want, or need, to learn about DTDs and schemas and validation. They
just need to be able to get their jobs done, to be able to find information
and reuse it, and to be able to collaborate. XHTML isn't going to give
anyone that. 

Let's say that we agree to call something a clause. If someone wants to work
with "tags," Epic allows for the creation of aliases. Oh, what we called a
clause you call a section? No problem. In a Smart Document, the task pane
can be phrased in any way familiar to the end user. They don't need to know
that when they push a button that looks like [1.1.1] that the hidden markup
is creating a third-level clause, or sub-sub-section, or just a nested
whatever. Same goes for XMetaL. 

But when they need to search the database to find standard boilerplate
clauses or something that they've used previously, XHTML is going to be of
very little help. If we load all sorts of attributes on XHTML to help us
identify what the information really is, it's no longer XHTML. Instead let
the implementers design robust user interfaces that are meaningful to the
end user, and let us design a robust DTD that will support the implementers
in 

2. From my understanding, the purpose of the committee is to solve the
eContracts problem, not to try to create a general-purpose DTD. A number of
years ago I served on the TCIF/IPI committee - Telecommunications Industry
Forum Information Products Interchange. We created the TIM DTD
(Telecommunications Information Markup). It's an interchange DTD meant to be
used from vendor to supplier (i.e. Sprint buys technology from Nortel and
Lucent and needs to be able to integrate all of the documentation with their
own). For a while there was a movement to try to expand the DTD so it would
serve other industries as well. The problem is that as soon as you begin
trying to reach too broad an audience, the markup becomes to loose to truly
be useful.

3. My personal philosophy is one of small, compact specific-purpose DTDs
that can be combined as need be to create larger information sets. My
contract DTD shouldn't look anything like my legal brief DTD or my technical
manual DTD. The end user doesn't make all of their documents look exactly
the same - different document types have different requirements. 

I'll head to the back of the room now ...

Mary

Mary P McRae
Senior Vice President and Principal XML Technologist
DMSi
email: mmcrae@dmsi-world.com
web: www.dmsi-world.com
cell: 603.557.7985