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: Thank you John, and good luck.

John, the points you bring up in your post are provocative and insightful.
I'll read it again, more closely, to be sure the layered value is not lost.
But at first glance, it sounds to me as though many of the points go
directly to which requirements will be in scope and which will be out.  That
will all be very useful as the TC brings our requirements process to a close
over the next few weeks.

John - it is clear from the content and context of your note that you are
resigning.  Based upon input from members of the TC, I accept it with the
understanding that sometimes certain paths will diverge, but friendships and
collaboration in other venues may continue.  And I thank you for your
contributions in this venue to date. I look forward to seeing the great
works you will, no doubt, continue to create and I hope the specification
that comes from this TC will be of use to you in your efforts.

With warm regards,
 - Dan Greenwood, Chair of the OASIS/LegalXML eContracts TC

|  Daniel J. Greenwood, Esq.
|  Lecturer, Massachusetts Institute of Technology
|  Director, E-Commerce Architecture Program
|  MIT School of Architecture and Planning
|  77 Massachusetts Avenue, Room 7-231
|  Cambridge, MA 02139
|     http://ecitizen.mit.edu
|     or http://www.civics.com
|     dang@mit.edu

----- Original Message -----
From: "John McClure" <jmcclure@hypergrove.com>
To: "Legalxml-Econtracts TC" <legalxml-econtracts@lists.oasis-open.org>
Sent: Wednesday, August 18, 2004 10:37 AM
Subject: [legalxml-econtracts] Standards For Whom?

> To the Chair:
> For over four years I have been fighting for XML Namespaces, CSS, RDF, and
> X/HTML to be explicitly addressed by a standard that I wanted much to be a
> success in the marketplace. I have explained and argued every which way
> these technologies, believing them all to be essential and key to XML use
on the
> web. For four years, I have been involved in what often seemed bitter
> about each of these issues. Nevertheless I have soldiered on through the
FUD and
> the delays and postponements, while these W3 technologies have all
> bound together as I said they would be many years ago as the backbone of
> Web. I did so with the hope that fresh voices of an OASIS-based TC would
> easily understand how these developments in the world of Internet
standards, do
> relate to the development of a standard for a legal instrument that is but
> of an amalgam thrown at developers to absorb during their professional
> But today's vote crystallized for me a continuing sharp divergence of my
> from what would otherwise be a consensus, on the same basic issues, for
> second tiresome time. Today's vote removes all constraints imposed by
> its accompanying architecture on one's schema implementation, constraints
> should instead be heartily welcomed by a group relatively unskilled in web
> architecture. I also had to finally acknowledge that this vote is matched
by a
> persistent palpable reluctance to commit to the use of RDF for semantic
> information. And it comes after a continuing lack of consensus about even
> role of CSS in our (oops) technical requirements. And it comes complete
> calls to 'create our own  XML namespace' as being somehow pertinent as an
end in
> itself, when the core issues are clearly about combining namespaces, our
> namespace, with the XHTML namespace, with the RDF namespace, with the
> namespace, and with the XEvents namespace. How to make these all play
> in a predictable manner during the markup of a legal instrument, now
that's the
> crying need. It is blatantly obvious to me that our most effective
> to the legal-software community would be to clarify how to use what
> rather than to add even further to the din. But instead, the future on the
> Committee appears to hold more of what HAS NOT worked -- creating yet
> XML dialect island that yes, can be validated on its own merits but no, is
> ignorant of multiple stubborn realities. Not very impressive to me.
> Now, as you surely know, my views are shaped by my software product plans,
> which happen to match those derisively and snidely today called "one-trick
> applications. That  unquestionably galled me, but also saddened me because
> points to the small effort being made to create a standard useful to the
> broadest audience possible.
> You see, I am creating a very relevant application for my customers.
> formulas and forms, XHTML, RDF, RSS, and so on. This is hardly an atypical
> document application, now or in the future. (And hardly a 'one-trick
pony'). So
> I have direct interest in a standard that uses XHTML. But without a
> with a specific orientation towards XHTML, I'm finding little incentive to
> collaborate further. The consensus became pretty clear today to create an
> incompatible standard that is decidedly unuseful to me or, I believe, to
> market.
> To be oriented towards XHTML, an XHTML-conforming application is required.
> that consists of an XHTML module, an RDF ontology containing the
definitions for
> resource-type property-names, and several standardized XSL and CSS
> But that's not the plan, which is unfortunate, since it disregards IMO
> anticipated contract transactions -- vanilla XHTML wrapped in a DSIG
> The practical reality being overlooked by this TC is that technical people
> guidance on these issues, today. They are the ones creating the large
number of
> contracts destined to be managed by XML-consuming and -producing contract
> management systems. IMO, without their buy-in, and without a force-in
> I do wonder what criteria will be used to judge the success of an XML
> for eContracts.
> I grant that direct XML contract authoring is an attractive solution to a
> certain set of users. However, the far larger group of users -- today --
> those generating and accepting form contracts on the one hand, and those
> constructing and then spot-editing their contracts on the other, using a
> document assembly application. Form contracts of course need forms
> Which need all the DHTML tricks of the trade. That is, standard XHTML +
> Javascript. But I'm not seeing a standard emerging much useful to the
> fielding numerous corporate applications that will put form contracts
before the
> general population as legal offers. For document assembly applications, I
> equally troubled: it would be odd if those applications were to implement
> eContracts dialect prior to complete XHTML 2.0 support. Very odd.
> Maybe your time horizons are diffierent from mine. I know that the world
> today awash in XHTML, and very little in any specific XML dialect such as
> envisioned here. Sure, developers are using the Dublin Core, and some are
> beginning to grapple with XBRL and even UBL. But please note carefully:
few use
> an OASIS dialect when a W3 dialect does the same job just fine. All by
> XHTML 2.0 does just fine for contract markup, without anything near the
> resistance that naturally comes to a new and untested dialect. That's the
> stubborn reality.
> Funny, until today, I had good reason to think that common sense would
> ultimately prevail.
> An architecture having an Authoring DTD distinct from a Publishing DTD --
> latter being Moduler XHTML comformant, with a transforming XSL stylesheet
> between the two -- seemed to be our ultimate destination, based on recent
> encouraging remarks from Jason and Rolly. I do believe such an approach
would be
> both useful and achieve decent market penetration. I admit however that I
> presumed it was implicitly understood that -- with a separate Publishing
> mandated for the critical offer/acceptance contract datastream exchange --
> an Authoring DTD threatened to appeal to merely a niche audience (as it
> That is, an Authoring DTD is but a contract-authoring aid that likely can
> adequately implemented by Word macros and Web services, outputting XHTML+
> then processed by document signature, management and workflow
applications. All
> of which will surely be XHTML 2.0 aware. And RDF-aware. And Dublin
Core -aware.
> Why RDF and DC? Because that's the W3 architecture being embedded in
> and editors; because informed decision makers are risk averse given a
> between an OASIS dialect and a functionally equivalent W3 dialect; and
> the RDF and DC are intellectually simple enough to be grasped without much
> effort. In short, you walk away from other standards, and people walk away
> you.
> And I suggest to you that many XHTML contract streams will be written by
> Why? Because it's absurdly obvious that XHTML 2.0 will be hailed as a
> XML-ified HTML, and the stampede will begin among both programmers and the
> magazine-educated. M$ surely does not ignore this -- in fact, significant
> development is ongoing now, and you can bet that both Dublin Core and RDF
> going into the o/s. Now, doesn't it make sense to go (but not to follow)
> M$ is going?
> Of course a successful standard is best based on an understanding of the
> needs of the belly of the market. I strongly assert that those needs do
> include yet-another-XML-dialect. Rather, the world clearly will be glad
that --
> with XHTML 2.0 -- there's no need to have a separate (OASIS) XML dialect
> their user-facing contract applications. Sure, for RDF descriptions of a
> contract, specialized dialects will emerge, and will be used by
> applications. And perhaps the eContracts dialect will become that
> dialect -- assuming of course that the dialect conforms to the RDF which,
> unfortunately, appears a very dim possibility to me at this moment.
> I do feel proud of my contributions to this group. I feel responsible for
> goading us back to life when we were without a charter for too long a
time. For
> writing a 70 page requirements document complete with data models. For all
> strawman markup examples. For the diagrams. For the many carefully-written
> doing my darndest to share my expertise, being as straight with the group
as I
> could be throughout. For the gift-wrapped Minority Report (whose future is
> to dispose). For helping Leff with the Resources page.
> I chuckled the other day when you talked about 'socializing' the Req Doc
> the F2F. Fine, but here's hoping someone will notice the elephant in the
> and then have the bravery to confront it.
> Ciao,
> John
> 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]