Re: [legalxml-econtracts] Thank you John, and good luck.

["Daniel Greenwood" <dang@mit.edu>]

And as a final note, John, given that you will remain on our TC list as an
observer (per your request), though not as an active Participant, I do hope
you will feel free to send us any continued comments you may have on the
progress of our TC Specifications from time to time.

Yours,
 - Dan Greenwood

----- Original Message -----
From: "Daniel Greenwood" <dang@MIT.EDU>
To: "John McClure" <jmcclure@hypergrove.com>
Cc: "Legalxml-Econtracts TC" <legalxml-econtracts@lists.oasis-open.org>
Sent: Wednesday, August 18, 2004 1:15 PM
Subject: [legalxml-econtracts] 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
> for
> > 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
> exchanges
> > about each of these issues. Nevertheless I have soldiered on through the
> FUD and
> > the delays and postponements, while these W3 technologies have all
> emerged,
> > bound together as I said they would be many years ago as the backbone of
> the
> > Web. I did so with the hope that fresh voices of an OASIS-based TC would
> more
> > 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
> one
> > of an amalgam thrown at developers to absorb during their professional
> lives.
> >
> > But today's vote crystallized for me a continuing sharp divergence of my
> views
> > from what would otherwise be a consensus, on the same basic issues, for
> the
> > second tiresome time. Today's vote removes all constraints imposed by
> XHTML and
> > its accompanying architecture on one's schema implementation,
constraints
> which
> > 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
> the
> > role of CSS in our (oops) technical requirements. And it comes complete
> with
> > 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
> XForms
> > namespace, and with the XEvents namespace. How to make these all play
> together
> > 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
> contribution
> > to the legal-software community would be to clarify how to use what
> exists,
> > 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
> another
> > 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,
> ones
> > which happen to match those derisively and snidely today called
"one-trick
> pony"
> > applications. That  unquestionably galled me, but also saddened me
because
> it
> > 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.
> Javascript
> > formulas and forms, XHTML, RDF, RSS, and so on. This is hardly an
atypical
> legal
> > 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
> standard
> > 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
> the
> > market.
> >
> > To be oriented towards XHTML, an XHTML-conforming application is
required.
> One
> > that consists of an XHTML module, an RDF ontology containing the
> definitions for
> > resource-type property-names, and several standardized XSL and CSS
> stylesheets.
> > But that's not the plan, which is unfortunate, since it disregards IMO
> most
> > anticipated contract transactions -- vanilla XHTML wrapped in a DSIG
> envelope.
> > The practical reality being overlooked by this TC is that technical
people
> need
> > 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
> strategy,
> > I do wonder what criteria will be used to judge the success of an XML
> dialect
> > 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 --
> are
> > 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
> controls.
> > 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
> developers
> > fielding numerous corporate applications that will put form contracts
> before the
> > general population as legal offers. For document assembly applications,
I
> am
> > equally troubled: it would be odd if those applications were to
implement
> an
> > eContracts dialect prior to complete XHTML 2.0 support. Very odd.
> >
> > Maybe your time horizons are diffierent from mine. I know that the world
> is
> > 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
> itself,
> > XHTML 2.0 does just fine for contract markup, without anything near the
> market
> > 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 --
> the
> > 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
> DTD
> > mandated for the critical offer/acceptance contract datastream
exchange --
> that
> > an Authoring DTD threatened to appeal to merely a niche audience (as it
> should).
> > That is, an Authoring DTD is but a contract-authoring aid that likely
can
> be
> > adequately implemented by Word macros and Web services, outputting
XHTML+
> markup
> > 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
> browsers
> > and editors; because informed decision makers are risk averse given a
> choice
> > between an OASIS dialect and a functionally equivalent W3 dialect; and
> because
> > 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
> from
> > you.
> >
> > And I suggest to you that many XHTML contract streams will be written by
> Word.
> > Why? Because it's absurdly obvious that XHTML 2.0 will be hailed as a
> great
> > XML-ified HTML, and the stampede will begin among both programmers and
the
> > magazine-educated. M$ surely does not ignore this -- in fact,
significant
> RDF/DB
> > development is ongoing now, and you can bet that both Dublin Core and
RDF
> are
> > going into the o/s. Now, doesn't it make sense to go (but not to follow)
> where
> > M$ is going?
> >
> > Of course a successful standard is best based on an understanding of the
> actual
> > needs of the belly of the market. I strongly assert that those needs do
> not
> > 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
> for
> > their user-facing contract applications. Sure, for RDF descriptions of a
> > contract, specialized dialects will emerge, and will be used by
> specialized
> > applications. And perhaps the eContracts dialect will become that
> specialized
> > 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
> the
> > strawman markup examples. For the diagrams. For the many
carefully-written
> memos
> > 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
> yours
> > to dispose). For helping Leff with the Resources page.
> >
> > I chuckled the other day when you talked about 'socializing' the Req Doc
> during
> > the F2F. Fine, but here's hoping someone will notice the elephant in the
> room,
> > 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
>
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/lea
> ve_workgroup.php.
> >
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/lea
ve_workgroup.php.
>