Overall requirements - structure v semantics

[Jason Harrop <jharrop@speedlegal.com>]

The agenda for our August 3 meeting includes:

> 2.  Review our requirements document with the goal of reaching closure
>     and/or determining what changes must be made so that we could vote on it.
> 

My view is that the requirement document should have teeth, that is, to 
be something which reflects decisions made by the TC which have a useful 
impact on the standards being developed.

If it is to have teeth, then i think there is still a lot of work to be 
done on it.

In addition to preparing descriptions of specific business contexts as 
suggested by Peter, a useful approach might be to try to create a list 
of half a dozen or less key issues/themes, which we can discuss one by one.

For me, one such issue would be the relationship between the structural 
and semantic layers.

Working Draft 3 (10 April 2004) of Rolly's document contains at 4.1.5 
the requirement that our XML syntax for contract documents "should be 
compatible with various XML semantic vocabularies or dialects, including 
those used in different vertical business sectors".

It seems to me that there are various questions that we need to discuss 
and resolve one way or another.  There are two key ones:

1. Do we want to support various existing vertical XML standards (such 
as ACORD for insurance, ISDA's FpML for financial products such as 
swaps/derivatives, real property), in addition to a semantic vocabulary 
we as a TC devise?

2. Are we saying people have to use our eContracts structural for 
contracts, or are we explaining a conceptual model which has a 
structural layer, and saying you can use whatever XML document format 
you like for that purpose (eg eContracts structural, WordML, XHTML 1, 
XHTML 2, DocBook etc)?

I'd love to hear where TC members sit on these issues.  Fwiw, my 2 cents 
are further below.

Once we know the answers to these two questions, we can look at possible 
technical solutions (eg inline markup, RDF, XForms, devise our own 
mechanism, or some combination).

---------

Jason's answers:

To question 1: I think that if we can do this in a clean way, without 
imposing unwarranted technical hurdles on people who might be 
considering using our work, then our contribution will be that much more 
compelling.  I'm keeping an open mind, and could go either way on this 
still.

To question 2: If the answer to question 1 is that we should be 
supporting existing vertical XML standards, then i think we have to be 
saying that people can use whatever structural layer suits their needs.

I say this because even if our structural layer becomes very successful, 
there will still be a lot of people who author contracts in Word 2003.

Word 2003 already includes a structural layer - its called 
WordProcessingML, and it includes paragraphs, tables, and some other 
stuff (including a lot of presentation).  When you use WordProcessingML, 
it seems to me there is little reason to also use our section, h, p etc.

But, there is a lot to be said for using WordML in conjunction with a 
semantic schema.  And this is precisely what Word is designed to make 
very easy.  It does this by validating the structure against WordML 
schema, and simultaneously but independently validating the semantics 
against your contract semantics schema.  (You could see their US patent 
application number 20040006744 for a description:

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040006744%22.PGNR.&OS=DN/20040006744&RS=DN/20040006744

For downstream business users, its this semantic data which is critical, 
and which Word 2003 is designed to make easy to extract.

So if we are intending to support different vertical schemas, our 
complete model would look something like:

+-----------------------------------------------------+
|                                                     |
|      Semantic layer (vertical XML schema)           |
|        (eg ACORD, FpML, or eContracts semantics)    |
|                                                     |
+-----------------------------------------------------+
                         ||
+-----------------------------------------------------+
|                                                     |
|      Connection mechanism (to be specified)         |
|                                                     |
+-----------------------------------------------------+
                         ||
+-----------------------------------------------------+
|                                                     |
|      Structural layer                               |
|      (eg eContracts structure, WordML, XHTML 1 or 2)|
|                                                     |
+-----------------------------------------------------+


cheers,

Jason