Concerning "A Pox on Validation's House"

[All quoted material from http://philringnalda.com/archives/002252.php]

> I would dearly love to gather up everyone who has ever
> attempted to teach English composition to anyone now
> involved in XHMTL/XML/DTD spec writing, so that I
> could give them all a medal for their efforts, and then shoot
> them all for their miserable failure to achieve anything
> resembling results.

Specifications aren't tutorials. The point of a specification is to lay
down a set of implementable rules, using grammar and terminology that is as
unambiguous as possible. The XHTML family of specifications are not without
their errors, but as far as specifications go, they are competently
written, and they are of utility to the people who possess the relevant
background experience.

For people like yourself, i.e. obvious newcomers to the field, I agree that
there is a staggering lack of introductory material on subjects such as
XHTML modularization and language mixing. This is surely symtomatic of the
fact that the implementers of the specifications tend to be conversant in
the language anyway; XHTML modularization is targeted towards companies
that have the time to develop derivatives of XHTML, not the common
person-on-the-street who wants to add a new element to the langauge. This
is no excuse for the lack of primer material, but it is almost certainly
one of the causes.

There are a set of simple XHTML modularization tests under the following
directory:-

http://infomesh.net/2002/m12n/test/

These are just personal tests, but you may be able to use them as a sort of
learn-by-example approach to modularization. There *are* some
modularization tutorials on the Web, but the ones that I have come across
are not all that good; they go under the "valiant effort" category.
Modularization can be a complex thing, and it's difficult to make it fuzzy
and cute.

The basics are easy enough, but they're very tedious to many, and this is
probably a big factor in putting people off.

> This forwarded email on some W3C list should have
> provided all the answers, [...] the email doesn't include
> the qname modules for RDF and DC

The modules are still available on the Web, but they have been superceded
by the Augmented Metadata approach [1], [2]. This was the result of a set
of conversations with Murray Altheim, whose insight and approach to the
entire debate have always been a source of much inspiration and
enlightenment.

> The thread on the W3C RDF IG list where he announced
> it is instructive, as rather than saying "well, hell, let's write a
> DTD so that people can shove RDF into their XHTML
> and still validate" the list goes haring off on some holy war
> about N3 and N-Triples.

The turn towards the RDF serialization war was a very sad indeed, but
difficult to prevent. Many of the issues in the RDF world are entwined with
one another so much that it's rare for a www-rdf-interest thread to remain
on one topic for long. I was not so frustrated about the lack of response
towards the embedding issues at the time since the RDF serialization war is
another one of my concerns.

The reason that we cannot simply write one single DTD for people to "shove
RDF into their XHTML and still validate" is that RDF is very
non-constraining, and DTDs are quite the opposite. You must know in
*advance* what predicates are going to be used in the RDF in order to write
the DTD.

RDF allows one to mix and match terms, to a great extent, from a wide range
of vocabularies. Once you write a DTD, this ease of extensibility vanishes.
People would basically end up writing a new DTD from scratch every time
they want to embed some RDF in their HTML--eek.

> I was planning on editing this, to tone down the
> rhetoric a bit [...]

Please note that, with all due respect, I resent your insultory tone, and
feel that your outburst has been woefully misdriected. It is *not* my
responsibility to explain modularization and language mixing w.r.t. XHTML
and RDF to the general public, and yet you strongy imply this in your blog
entry. Notwithstanding, I have spoken out on the complexity of the language
before, and to some extent I feel that the condescending tone and position
that you take up would have been acceptable to a great extent had it have
been abstracted.

Chiding harworking volunteers and working groups without enough resources
to provide the materials that you require is, however, not acceptable.

> After all, I've spent almost an entire day chasing
> my tail on this, without any results, so I think I'm
> entitled to be a little crabby.

Perhaps so, but does this entitle you to be rude to volunteers who devote a
portion of their free time to resolving such issues?

The technical community must first settle upon an approach before they can
evangelize it to the public; they need to balance a tremendous amount of
conflicting interests, ideas, and approaches before they can make their
descision. It takes time for approaches to be suggested; it takes time for
implementations of the best ideas to be pitted against one another; it
takes time for the people in charge of the specifications to be convinced
beyond all reasonable doubt that one approach is demonstrably superior.

The W3C RDF Core WG (the group responsible for any issues regarding RDF)
have the RDF-in-HTML issue on their official RDF issues list [3], but you
will note they also have a tremendous amount of other issues on the list,
and not a great deal of resources to deal with them.

If you want to help, I suggest that you learn about all of the relevant
problems and in the technologies involed, and then join in the public
discussions on how to settle the issue.

Sidenote: I have said that it's the RDF Core WG's responsibility so come up
with a standardized approach for associating RDF with HTML. However, it
isn't clear whose responsiblity it is to provide education and outreach
material on the subject.  It is my belief that where the community do not
provide explanatory resources for a specification, the W3C are more than
obliged to provide this.

The WAI activity of the W3C have an "Education and Outreach" Working Group,
since some of the concepts in their specifications are so difficult to get
across. If every W3C activity had EO and QA (Quality Assurance) factions,
perhaps things would be different, but these are expensive to set up.

I must underline the point that each of these technologies must be taken on
a case-by-case basis. I have been part of the RDF-in-HTML discussions for
quite some time now, and one of the major problems that I have encountered
has been the variety of opinions that people hold. It's incredibly
difficult to reach consensus upon this issue. It should have been resolved;
it hasn't been resolved; all we can do is move on. The "RDF-in-HTML:
Approaches" article was designed to be a primary anthology of the
approaches proposed thus far. It was not, however, meant to be partial to
one solution, or be some sort of primer for each of the approaches. We have
to do things one step at a time--gather the approaches, choose the best
one, and document it.

At the risk of repeating myself to get my point across, the responsiblity
of the next step--choosing the best approach--lies with the RDF Core
Working Group, although they must take into consideration the views of the
RDF community.

> After all, XHTML modularization is over a year old, and
> RDF is over three years old: that seems like enough time
> for someone to come up with a DTD skeleton that would
> let a content producer just replace a few element and
> attribute names, or better yet a DTD wizard that would
> ask what elements you need to use, what attributes you'll
> give them, and where in your XHTML you want to put
> them, and then spit out a working, valid DTD.

This is an intreguing idea, but it requires someone with enough volition
and technical resources to produce it, and there aren't a great deal of
those people around. With RDF applications such as Dublin Core, which has a
set property enumeration, producing a DTD is easier, but there is still the
question of whether embedding the XML RDF in the HTML is the best approach.

P.S. Note that www-archive is a publically logged email list.

[1] http://www.altheim.com/specs/meta/NOTE-xhtml-augmeta.html
[2] http://infomesh.net/2002/rdfinhtml/#augmeta
[3] http://www.w3.org/2000/03/rdf-tracking/

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://purl.org/net/swn#> .
:Sean :homepage <http://purl.org/net/sbp/> .

Received on Monday, 12 August 2002 16:33:11 UTC