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


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [legalxml-econtracts] Overall requirements - structure v semantics

Good note, Jason. A few comments.

1. The XHTML @property attribute is the place for inline semantic markup, that
is, XHTML provides adequate support for those dialects already - so I don't
think we need to specifically address any particular vertical.  Non-normative
examples (in the tech spec) that use them are fine, but normative material
should not. I definitely do not want WordML mentioned in any normative section.

2. The notion that we are more defining an architecture -- with a specific
implementing markup schema -- is one that I've had for awhile also, however
there is a crucial presumption at work here worth reviewing. To me, the
contract -- produced by an XSL-T -- ultimately must conform to a common schema.
That common schema is best made XHTML 2.0 based, ie the Publisher schema, in
order to meet presentation fidelity requirements. This view does track with what
I've earlier said -- the PPT I once posted to the list (and attached here),
shows that the common end-point of a contract doc is a digitally-signed package
that contains
	(1) an XHTML or SVG file (called the "User Agent" XML file), with or without
	@property markup for semantics that are 'agreed-upon by the parties'
	(2) RDF file(s) reflecting semantics (not) agreed upon by the parties; and
	(3) other files needed for authoring, presentation, or management

3. Maybe you're now arriving at the same conclusions as me about what
constitutes the "exchanged file". The definition of what an "exchange contract"
_is_ has bedeviled our conversations to date, leading I think to several
unfortunate miscommunications. As you know, I think the authored-file (that
precursor to the normative XHTML file) would rarely if ever be an object of
exchange between parties. Further you probably understnad that since my focus is
solely on "that-which-is-exchanged", then my impatience with precursor formats
is sometimes palpably clear. I'm sorry for that, because I do understand (and
support) the central importance that authoring plays in yours and others
requirements. In this vein, I am optimistic that having a separate schema for
Author v Publisher is a potentially fruitful path for us all.

Since the definition of an "exchanged file" certainly is an item that needs to
be discussed in the requirements document, your comments below are quite useful.

>-----Original Message-----
>From: Jason Harrop [mailto:jharrop@speedlegal.com]
>Sent: Sunday, July 25, 2004 6:19 PM
>To: legalxml-econtracts@lists.oasis-open.org
>Cc: Mary McRae
>Subject: [legalxml-econtracts] Overall requirements - structure v
>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
>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:

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)|
|                                                     |



To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]