OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Practical Problem (was Question About Namespaces and DTDs)

[ Lists Home | Date Index | Thread Index ]
  • From: "Winchel 'Todd' Vincent, III" <winchel@mindspring.com>
  • To: xml-dev@lists.xml.org
  • Date: Thu, 27 Jul 2000 02:36:57 -0400

To XML-DEV:

I appreciate the feedback about namespaces and DTDs.  I still have some
questions and concerns.  Your comments have been interesting.   If you would
indulge me once more, I'd would like to ask for a bit more feedback on the
practical problem that led me to ask about DTDs and namespaces.

I apologize in advance for the length of this post.

I am involved with a group that is attempting to define open,
non-proprietary standards for legal documents in XML.   It is a volunteer
group that started with 17 people in November 1998 and is up to 540.  All of
the people involved are highly qualified, bright, motivated professionals.
However, only a minority are XML experts (or, if there are more XML experts,
they are lurking).  Conceptually, the active members understand the power of
XML, but they have their day jobs as lawyers, judges, court administrators,
etc. There are professional technologist among us.  However, I think it is
safe to say, most members do not have time to keep up with the steep XML
learning curve and all the new XML acronyms.  (We're trying, but again,
everyone has day jobs.)

For practical reasons, we have decided to use DTDs for the first round of
our specifications.  I am not here to debate the readiness of XML-Schema,
I'm simply relaying the fact that based on a number of practical factors, we
are currently using DTDs.  At some time in the future, we intend to use
XML-Schema (I'm not sure when).

Validation is important to us.  Namespaces are also important to us
(although we're not using them . . . and, it seems, apparently we can't if
we want to validate *and* use DTDs).

To date, we have taken a document-centric view, since most lawyers are
accustomed to using and handling documents.  So, for instance, some of the
workgroups are contracts, court filing, transcripts, public law, research,
and integrated justice.

Each of these groups has their own constituency.  In loose terms, you could
say that each of these groups are their own namespace (with a little "n").
However, within each of these groupings are a wide variety of documents with
their own unique structure and subject matter vocabularies.  For instance,
inside court filing, there is civil, criminal, juvenile, probate,
magistrate, administrative, small claims and others.  Thus, you could say,
there are namespaces within namespaces.

You might map it out like this (although you could do it other ways as
well):

Legal
    CourtFiling
        Civil
        Criminal
        Appeals
        Probate
        Magistrate
        Juvenile
        Bankruptcy
        Small Claims
        Traffic
        Administrative
        Military
    Transcript
        Real Time
        Final
        Depositions
    Contract
        Real Estate
        Insurance
        Wills (not really a contract, but generically a "stand alone
document"
        . . . tons of others . . .
    Public Law
        Legislation
        Statutes
        Bills
        Administrative Law
        Ordinances
        . . . others . . .
    Integrated Justice
        Arrests
        Rap Sheet
        Fingerprints
        . . . others . ..
    Research
        Judgments
        Case Law
        Law Reviews/Journals

There are also other things like deeds, UCC filings (in the US), patents,
etc.

I like to refer to these document categories as "vertical".  If Namespaces
(with a big "N") worked, I would think they would each live in their own
Namespace.

In doing document analysis, I have found that there are a large number of
elements that are primitives.  These primitives can be found in many, but
not always all, of the vertical document types listed above.  I like to call
the primitives "horizontal" elements.  To complete the analogy, some
horizontal elements cut across vertical documents.   For instance, the legal
industry uses a very specific type of <Citation> that is found in nearly all
legal documents. This is a horizontal element with a complex content model
that would need to be included, at times, in all vertical document types.
<Citation> could probably live in its own "horizontal" Namespace.

We have two workgroups, "Legal" and "Horizontal" that attempt (or will
attempt as we do more work) to harmonize the other groups.

Mixing namespaces (again, with a little "n") is very important for the
following reasons.  Consider two people who form a contract (in XML based on
a Contract DTD/Schema).  Over the course of a couple years, they exchange
correspondence in the form of letters (Legal Letter XML).  Two years
later, there is a dispute over the contract.  Litigation ensues.  There are
several contract issues that are governed by a statute (Statute XML).  There
is also some old case law (Judgment XML) that governs the issue.  And, there
is a progressive law review (Legal Publication XML) that might help sway the
judge.  During discovery (information gathering time before case actually
begins), a deposition (Transcript XML) is taken.that will be used as
evidence.

(Realize, of course, that the people who create and publish all of the above
document types are all very different people, from very different parts of
the legal industry, with very different business requirements -- judges,
legislators, academics, court reporters, lawyers, large publishers.)

(Ignore, for the moment, the fact that there are lawyers around the world
that speak and write in different languages. :-)

Plaintiff's lawyer writes a "Motion for Summary Judgment" (Court Filing XML)
and a Brief in support of the Motion (Court Filing XML).  To write this
document, the lawyer will use small bits and pieces of all of the documents
listed above.  Typically, the lawyer will write new text in support of
his/her argument and will bolster the argument with pieces of any text
that helps.  In Word and Word Perfect, this is done with a simple cut and
paste (although that often requires reformatting the text . . . taking out
tabs, white space, strange embedded characters, etc.)

The following is a very simplistic example of what the Brief might look
like.


<Legal>

    <CourtFiling type="Brief">

        <Caption> . . . . title, party names, case number . . . </Caption>

        <Title>Plaintiff's Brief in Support of Motion for Summary
Judgment</Title>

        <BriefBody>

            <Paragraph>Plaintiff makes this Motion for Summary Judgment
pursuant to Code Section 12-34-01 . . . . . Section
12-24-01 states:</Paragraph>


                <Statute> . . . . marked-up quotation from Statute XML
namespace . . . </Statute>


                <Citation>Section 12-24-01.<Citation>


            <Paragraph>Clearly, Plaintiff should prevail on the merits based
on the following testimony from Defendant who said:</Paragraph>


                <Transcript> . . . . marked-up testimony from Transcript XML
namespace </Transcript>


            <Paragraph>Indeed, in 1890, in the most famous case decided in
this state, Justice Henry held:</Paragraph>


                <CaseLaw> . . . .marked-up quote from CaseLaw/Judgments XML
namespace . . . </CaseLaw>


            <Paragraph>Defendant argues that Justice Henry's opinion is not
controlling.  However, the famous Professor Ledbetter in his recent law
review article states:</Paragraph>


                <LawReview> . . . .marked-up quote from Law Review/Journal
XML namespace . . . <LawReview>


            <Paragraph>In conclusion, Plaintiff ought to win and win
big.</Paragraph>

            <SignatureBlock> (not intended to mean a W3C XML-Signature)
                <Date> . . . </Date>
                <Name> . . . </Name>
            </SignatureBlock>

        </BriefBody>

    </CourtFiling>

</Legal>


Although there is often structured text at the top and bottom of the
document.  The body of the document is very unstructured.  It does not lend
itself to database structures or highly abstracted structures.  Still,
certain types of documents have very distinct structures (contracts are very
different than statutes, for instance).

There are many elements that are horizontal and that can be used
interchangeably in all of these documents.  There is, however, a great
opportunity for element collision.  Just as an example, in the court filing
world, a "timestamp" means something very different than it does in the
transcript world.

Further, as a practical matter, it is necessary for constituencies in a
particular legal sub-industry (e.g., integrated justice, court filing, or
transcript) to be able to work together on their own "namespace" without the
bother of constantly talking at cross-purposes with people in other
sub-industries.  The long-term goal is to harmonize the namespaces, but in
the short-term, the namespaces need to be developed by subject matter
experts in their own field, at their own pace (at least, this is the way it
is currently
happening).

If several DTDs are created for court filing, contract, transcript, etc.,
and this information *must* sometime mix . . . how is it we do this without
a Namespace standard that work?  Not only works, but works well?

So, this is the practical problem.  Comments welcome.

Thanks,

Todd

See http://www.legalxml.org/ for more information.

















 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS