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