Re: [RDFa] ISSUE-28: following your nose to the RDFa specification

Hi Dan,

Since RDFa could be processed server-side by pipeline tools, and
client-side by an assortment of parsers, then I think it's legitimate
to have different ways that RDFa might be spotted. My interpretation
of the proposal under discussion is that it would give us the
following scenarios:

No DTD and no profile: it's legitimate to run an RDFa parser over an
HTML/XHTML document, but you might not find anything. At worse you
might find things like <a rel="license" ... >, etc., which are already
defined by HTML/XHTML. But of course you might find RDFa constructs
like @about and @content. This covers the blog situation, for example.

A DTD: As you say, a client-side processor might not be able to detect
this, so it is no different to the previous situation. A server-side
processor should be able to, though.

Using @profile: A well-know URI is used to indicate that there is
mark-up available to an RDFa parser.

So I guess the question is what the significance of the second
statement is, and how we should word it. I.e., is there a way of
wording things to say that DTDs can indicate to server-side processes
that we require RDFa parsing, without that wording carrying the
'semantic' baggage that you are understandably trying to avoid.

(I have to say I don't mind either way, since in most use-cases I can
think of for RDFa, it seems best to just run a parser across the
document, no matter what the value of @profile or the DTD.)



On 19/06/07, Dan Connolly <> wrote:
> On Mon, 2007-06-18 at 17:00 -0700, Ben Adida wrote:
> >
> > Issue #28:
> >
> >
> > DanC asked us: "how does one follow one's nose to the RDFa specification
> > from an HTML+RDFa document?"
> >
> > I propose that we respond to this question by pointing to the DTD
> > declaration we now recommend for XHTML1.1+RDFa documents.
> >
> > I also propose that we specify an official W3C profile for XHTML1.1+RDFa
> > which would include a GRDDL transformation for XHTML1.1+RDFa. We should
> > encourage publishers to use this profile when it's possible, though we
> > should not to developers of RDFa consumers that this profile may not
> > always be present, since RDFa is built for copy-and-pasted, widgets, etc...
> >
> > Thoughts? Comments? Remember, send a note even if you simply agree!
> Hmm... surely the copy-and-paste caveat applies to the DTD as well, no?
> Is the DTD optional? The caveat seems to apply to the MIME
> type too ("In the case of XHTML1.1+RDFa, application/xhtml+xml.")
> If somebody can't change the top of the document,
> I find it hard to believe that they could change the MIME type.
> I'd sure like to see clarity on requirements such as "RDFa markup
> must work when pasted in the middle of an HTML-as-she-are-spoke
> document". I think it's best to be clear that this is a goal
> of RDFa, but we don't expect to fully meet the requirement
> until in-progress HTML specs mature.
> I support specifying a profile, without reservation.
> I don't support using DTDs as part of the follow-your-nose
> trail; they're not visible from XPath, I don't think;
> are they visible from javascript? SAX has a relevant event,
> but I have some vague feeling SAX parsers don't have to fire it.
> If others are satisfied, I suppose I can live with it,
> but it doesn't appeal to me at all.
> Way back when, I asked in comp.text.sgml whether DTDs were intended
> to convey semantics this way, and I was convinced by Erik Naggum
> that they are not.
> Ah yes... relevant parts of the discussion are still available...
> "There are many ways to standardize semantics and to allow people
> to share information in useful ways.  Standardizing DTD's is not among
> them."
>  -- Eric Naggum, Nov 9 1993
> --
> Dan Connolly, W3C

  Mark Birbeck, formsPlayer | +44 (0) 20 7689 9232 |

  standards. innovation.

Received on Thursday, 21 June 2007 09:47:25 UTC