[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 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]