W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2001

RE: RDF in XHTML [was: Re: Authors describing what their URIs mean]

From: Joshua Allen <joshuaa@microsoft.com>
Date: Mon, 16 Apr 2001 01:53:47 -0700
Message-ID: <4F4182C71C1FDD4BA0937A7EB7B8B4C1D15804@red-msg-08.redmond.corp.microsoft.com>
To: "Murray Altheim" <altheim@eng.sun.com>, "Seth Russell" <seth@robustai.net>
Cc: "Danny Ayers" <danny@panlanka.net>, "Sean B. Palmer" <sean@mysterylights.com>, "RDF Interest" <www-rdf-interest@w3.org>
> I long ago gave up proselytizing validation; if you don't feel it's
> important, go right ahead and create well-formed XML. I find
validation
> in most instances to be worth the trouble, like I find a Java debugger
> helpful. If you've got an XHTML plus SVG document and its acting up,
> I hope you have a DTD.
> 

On the other hand ... the XHTML DTD certainly does not provide
assurances that the script contained in a <script>..</script> block is
valid, nor does it give you any help when debugging the CSS in your
<style>...</style> block.  In fact, I would be concerned if the XHTML
spec decided to take on the burden of validating scripts and styles,
just as I think it is out-of-scope for the spec to be placing mandates
on the metadata that ships with a page.

I think I see your point about the <rdf>...</rdf> element, though -- if
you defined such an element as (#PCDATA) it would still break as soon as
we stuck XML with any namespaces in there.  Is that a correct assessment
of your reluctance?  It seems rather ironic that XHTML can happily
validate purely random text in particular elements, but pukes as soon as
that text becomes well-formed.  In other words, if I decided to use a
new scripting language that was based on XML and namespaces, as soon as
I use it in my <script /> block, the page won't validate -- XHTML: use
anything but XML..

> is going to make validation of six or seven author-designed namespaces
> by *any* methodology extremely difficult. XHTML modularization doesn't

This is the problem of RDF, isn't it?  In fact, the Cambridge Communiqué
[1] seemed to conclude that XML Schema is *not* necessarily appropriate
for RDF, and RDF is meant to be used with the RDF-Schema spec instead.

> web pages will likely be quite a bit more difficult if the markup
isn't
> valid. In fact, a lot more difficult. I've got a small Java
application

I think you are right about this one.

> (kinda lost track). I don't think you're going to see a stronger set
of
> semantic elements inside of XHTML, nor do I see a trend toward
improving

That seems wise.

> read up on HTML and can make web pages. It'd be an order of magnitude
> easier to get them to use <author> and <abstract> elements than to use
> some funky namespace markup, but the direction isn't that way. Sorta

I can see what you mean here -- I am not so sure that the ultimate goal
of RDF is to provide for a common set of semantics that everyone agrees
upon, though.  Dublin Core, for example, has built a lot of consensus,
and is therefore a sort of "de-facto" metadata markup.  But this makes
RDF (in a way) irrelevant to DC's goals (DC does more for RDF than RDF
does for DC in the year 2001). RDF is exactly about how to do metadata
when you *can't* get everyone to agree (which seems to be a safe
assumption these days).  It allows people to build and evolve their own
tools while still providing something of a bridge to the future.  This
is why I compare the metadata section to the <style>...</style> block
and point to the W3C opinion that RDF Schema is independent of XML
Schema.  RDF is meant to be incredibly abstract and processed by
machines that may or may not understand various pieces of the RDF.
You're right that a messed up RDF statement could be very expensive to a
company, but again I feel the validation of RDF statements is the
problem of RDF and not XHTML.

Regards,
Joshua


[1] http://www.w3.org/TR/1999/NOTE-schema-arch-19991007
Received on Monday, 16 April 2001 05:11:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:48 GMT