Lists Home |
Date Index |
From: "Jelks Cabaniss" <firstname.lastname@example.org>
> I'll just add that simple functionality and common sense appear -- at
> least temporarily -- to have triumphed over byzantine theological
> imperatives. :)
XHTML 2 certainly seems to have a lot going for it. There is a big
trend at the moment against the 200-element-type DTDs for publishing,
and towards smaller ones, and things like allowing hrefs more places
and making the div structure nest (like ISO HTML 4!) properly,
fit in with the current trends. (Probably the reverse is true for data
schemas: WXS encourages naming similar things differently.)
But I wouldn't rush to call the logic of most W3C recs byzantine: on the
contrary, the rationales for most decisions are easy to fathom, remembering
they are designed to help promote the businesses of the stakeholders who
involve themselves in the standards. That many of the current
crop of specs (XQuery, XLink) concern themselves with what to
do with documents before they have been assembled or after they have
been parsed is hardly surprising: the business requirements for the core
specs have been met and they are getting on with trying to exploit that core.
Which means that we should not sulkily rely on the W3C to come to our doe-eyed
rescue if we have have "core" requirements that W3C has decided not to address.
Rescue will have to come from other forums: ISO, xml-dev and the open
source community, OASIS and consortia. How to nurture this kind of thing?
Add support for non-W3C technologies as part of your product offerings:
SAX, Dublin Core, ODRL, RELAX NG, Schematron, OASIS catalogs,
RDDL, the MIME-types in XML RFC, XAR, DSDL, ODRL, etc. so that
the general bar is lifted. It is no use complaining about W3C if we don't
support the freely available technologies that are already here, and which
could benefit from a network effect.