Minutes Draft from the OASIS Legal XML Member Section Electronic Contracts Technical Committee Secretary (File id: MIN0119)

["Dr. Laurence Leff" <D-Leff@wiu.edu>]

                     Minutes, Teleconference January Nineteenth
       Organization for the Advancement of Structured Information Standards
                 eContracts Technical Committee

Present: Peter Meyer, Dr. Laurence Leff, Daniel Greenwood, Dave Marvits
Started 18:10

We began with item 2.10 of the list which concerned whether we should the
loose model or the standard or tight model.  The "list" can be found
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/email/
and is "Development Steps for TC Specification - revised" mailed by
Mr. Meyer on October 28th 2005.

The chief technical difference concerns when the item tag and block tag
are at the same level.  

The loose model would allow block and item tags at the same level,
that is, in a "container," arbitrarily intermixed, e. g.
<block>
   <block>   </block>
   <block>   </block>
   <item>    </item>
   <item>    </item>
   <block>   </block>
   <item>    </block>
</block>

The standard model requires that if one mixes block and item tags at
the same level, that the block would be first.  That is,

<block>
   <block>    </block>
   <block>    </block>
   <item>     </item>
   <item>     </item>
   <item>     </item>
</block>

The tight model means that within a container, one would have 
only block elements or only item elements.

<block>
  <item>
     <block>    </block>
     <block>    </block>
  </item>
  <item>
    <item>     </item>
    <item>     </item>
    <item>     </item>
  </item>
</block>

Also, noted was that attribute values are not constrained in the loose model.

The loose model was identified as useful for quoted and attached material.  
It is also useful when one is converted a document that was sent as
a file in a word process format such as a Microsoft Word file.
The loose model was also identified as being best for the exchange of
material.

However, we identified at least one problem with the loose model, it
makes it difficult to apply numbering in the output rendering.

One member suggested the characterization that applications should be
able to receive as input documents in the loose model but they should
output the tight model.  However, the concensus was to reject
that characterization.

The group went on to the philosophy that people will extend the
schema.  Some of these extensions will be for vertical areas.   Users
in real estate are currently using standards such as PRIA and MISMA.
And, of course, there is UBL which is "a set of business elements."
These tend to focus on the data being exchanged and are good for
marking up "business terms."  However, they do not provide for the
narrative text and do not mark up that part of a contract or sales
document that would be considered "terms and conditions."

Obviously, both forms of markup are needed and we discussed how our
standard might help people do both.  On the other hand, we discussed
whether these issues would be part of our first specification.
Having a first specification would help give our TC credibility, e. g.
within OASIS and improve our own morale.  But most importantly, a
first specification will allow interaction and traction with the
marketplace.

Philosophically, we should accept that others should be able to make 
extensions and raised the question:  
Should we provide a standard way for others to do this
and to add elements specific to their area, and still ensure that
all those communities would still then be able to use processing tools?

We also discussed the complications and difficulties created by
"smorgashboard" standards such as Docbook. 

Resolved.  That our specification will include a schema based on the
"loose model."  It will also include a schema based on the "tight model"
that is a subset of the standard schema.  It would be an "example" of a
"working schema" and how  one might do a subset.  

We will recognize that people will create their own variations
and/or can use whichever of the "loose," "tight," or "standard" models
that meets their needs.

The group spent about ten minutes on item 2.11 of the list, handling
ID and IDREF.

XML Schema and XML DTD provide an ID IDREF mechanism and will validate
that every time a name is used for an IDREF attribute, it recognizes 
that it corresponds to a name used in an ID attribute.  (Also, it
ensures that the smae name is not used in two ID attributes -- ED)

If a document is in several fragments, an ID in one fragment won't be
validated against an IDREF in another fragment.

Mr. Peter Meyer will talk to the developer at Elkera more about this
issue to get more details and will see what was done on docbook.
This was set as an action item by the TC.

The TC set the next meeting for February Sixteenth at the usual time
and adjourned at 19:32 New York City time.