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: Minutes Draft from the OASIS Legal XML Member Section Electronic Contracts Technical Committee Secretary (File id: @@2551)

                   Minutes Teleconference of July Twentieth
                      OASIS eContracts Technical Committee

Came to Order at 18:07 Eastern Time

Rolly Chambers
Laurence Leff
Dave Marvits
Peter Meyer

At the beginning of the meeting, we had a discussion of possible liason and
collaboration contacts.  This included the fact that OASIS Legal XML
Member Section Electronic Court Filing is in the process of reactiviting
its Court Document subcommittee.    Also the Associated
General Contractors is starting an effort in XML which includes 
a $90,000.00 grant to start work on development.

Mr. Daniel Greenwood, in saying he could not attend the meeting,
suggested that we try to make a decision on a host schema.  We discused 
whether or not the issue is ripe for such a decision.

We discussed the goals and ideas when the Structural Markup Subcommittee
made their suggestions for basis the narrative markup upon the XHTML 2.0.
This discussion included the following issues. 
  We were hoping that XHTML would have more market traction.
  Now, there is concern that they haven't eliminated certain markup that made
  the structure more complicated including H1 to H6
  Also, there is concern that XHTML is too "loose" a markup, and thus to
  make it rigorous enough for our purposes, must change container and
  structural elements.  If we do this, it won't be XHTML.
  Can some of the issues of looseness be addressed with tool development
  and an authoring environment?

We discussed why choosing a host schema is a tough choice and "we can't
just pick one and go on with it"  The decision impacts everything that proceeds
including rendering and authoring tools. Yet, it is difficult envisioning how
a result that doesn't exist will fit with a contract mark up.

It would help use our time more effectively if we were to eliminate 
some of the candidates on "fundamendal" grounds so we can address 
"two or three."

There was an informal agreement to eliminate DITA as it was not intended
for documents.  Dita provides tags for marking up small
bits of text in an online education or help environment.

We then discussed eliminating Microsoft WordML as a candidate.
An evaluator pointed out that one could create a WordML file in 
edit or notepad and have it load into Microsoft Word.  
One can include foreign XML in that input.  One can do a complete
round trip of saving and reloading and have that XML remain intact.

Unfortunately, Microsoft Word generates very large output
files that are not feasible to edit with a tool like edit or notepad.

On the other hand, there are plug-ins for Open Office that will read
and write Text-Encoding-Initiative files.  

Of course, there is concern about the possible proprietary  nature of
the WordML standard.  Of course, we could "bring the entire weight
of the Legal XML eContracts Technical Committee" to bear on Microsoft
to get them to work with us on this issue.  It was pointed out that
they are now restructuring their sales force on a vertical industry basis
and it was suggested that an appropriate letter might elicit 
some self-interested cooperation from that company.

That lead to a discussion of the importance of having a particular XML
format being processed natively or being handled by various transformation
schemes as generally one can write an XSLT style sheet or program to convert
from one XML format to any other.  Of course, the information needed by
the target markup must be available in the XML being transformed.

There was a discussion of the importance of a "grammatical paragraph."
This was defined to mean that a section MAY NOT contain paragraphs and
lists as siblings--lists are always within a paragraph.  Does this make
authoring and moving text easier?  Does it make designing robust
rendering engines easier?

Then we discussed of why we should have a host schema and what we might
gain from one.  These included:
   a) We gain access to the tools that others developed for processing and
      rendering that host schema.
   b) Using a particular host schema may get us some market traction.
   c) If we used a host schema, it would save the technical committee
      the time to develop a new one from scratch.

This lead to a discussion of how difficult it would be to create a new
schema.  It was observed that one could envision quickly constructing  a 
few tags for paragraphs, lists, sections, etc. and have a schema for
structural markup.  However, one member said
there were many details that interact with how one writes rendering 
and other applications.  

Then, we discussed simply defining tags for contract-specific stuff such
as party lists and signature blocks, and allowing them to be embedded
in other host schema.  This could done using "profiles" analagous to the
approach taken by the Electronic Court Filing Technical Committee.
Specifically, they have profiles for communication methods that transmit
the court filing XML.  For example, they have a web services schema
and will be developing a "sneaker net" profile.

Then, we discussed acceptance for authoring.  Obviously, it easier
for "geeks" or members of this technical  committee to author an
XML document than for a secretary in an attorney's office.  

However, it is not clear whether choices in the host schema or the
structuring of such things as lists and paragraphs will make
a difference.  Would such changes or decision make it easier for the 
hypothetical secretary to learn and use the schema.  And would an improvement
that we could hypothetically make in the tag structure be sufficient
to get them to learn and use the XML markup; or, or to use one member's
is our effort in this direction doomed to failure like the person 
trying to shovel out the tide?

As we realized that it was about 19:10 Eastern Time, we had to decide
how we can move forward.  We went back to the earlier suggestion,
that "we all go off to our corners" and try to eliminate some of
the candidate schema.

We will meet in two weeks at the same time and day of week.  At that
meeting, we will also determine which day of the week we will
meet during the Fall of 2005.

Meeting ended at approximately 19:15 Eastern Time

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