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: 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

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

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.


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