W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > December 2007

Re: Small change to the relationship between head and body during parsing

From: Ivan Herman <ivan@w3.org>
Date: Thu, 20 Dec 2007 14:07:41 +0100
Message-ID: <476A691D.4030306@w3.org>
To: Mark Birbeck <mark.birbeck@x-port.net>
CC: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>
Hm. I am not sure...

What would be the case with an xmlns setting in the <head> element? Your
model would mean that those xmlns settings should be valid for the
<body> as well. This is very counter-intuitive for anybody used to
proper XML handling, because it would be wrong from an XML point of
view. If, in any later version of RDFa, we decided to use xml:base, for
example, then we would run into the same issue (I guess the same holds
for xml:lang, and possibly other that I may forget). I think I would
prefer to stay with the clean XML model.

Yes, there are special elements in the <head> that have a 'semantic'
effect on the rest of the document (your <base> example, for example).
This is a consequence of the html semantics, and we may have to add
special rules in a later release to account for that if we need to. But
I do not find those arguments convincing enough to introduce a hidden
DOM reorganization...

B.t.w., your example:

<link id="dc" rel="prefix" href="http://purl.org/dc/elements/1.1/" />

is actually not solved via the DOM reorganization either, it would need
some extra 'semantics' in RDFa anyway...

Sorry Mark:-)


Mark Birbeck wrote:
> Hello everyone,
> I've made a small change in the draft to the way that processing
> occurs in terms of the hierarchy. Ordinarily I'd propose this to the
> group, have discussion, etc., but given we are up against it in terms
> of time, I've put it straight into the draft in a self-contained
> block, so that if the consensus is against what I'm suggesting, it is
> easy to simply remove it.
> I'll explain the changes first, and then the justification. The change
> is in a note, as follows:
> <div class="explanation">
> Note that since the head contains information that determines how the
> body should be parsed, the [evaluation context] as set at the end of
> processing <code>head</code> is then passed to the processing of
> <code>body</code>. It is <em>as if</em> instead of the DOM looking
> like this:
> <example>
> document object
>   |
>   |__ html
>         |
>         |__ head
>         |
>         |__ body
> </example>
> it looked like this:
> <example>
> document object
>   |
>   |__ html
>         |
>         |__ head
>               |
>               |__ body
> </example>
> </div>
> In current documents this is unlikely to make any difference at all.
> However, my motivation for doing this is so that any [URI mappings]
> that are set in <head> get passed on to <body>. This allows us to
> invent some new scheme in the future, such as:
>   <link id="dc" rel="prefix" href="http://purl.org/dc/elements/1.1/" />
> or whatever we come up with, and have the prefixes apply across the
> document. With the current parsing model that wouldn't work.
> Note that this is important for a number of reasons:
>   * when we come to look at HTML we can do CURIEs without having to rely
>     on @xmlns;
>   * there was a lot of opposition to using XML namespaces _anyway_;
>   * it is actually more 'logical', since the head does already set
> information for the
>     document that could not be determined by applying a simple
> hierarchical processing
>     model (for example, <base> would not apply to the entire document);
>   * the IPTC had a lot of problems with the prefix mapping question,
> because they
>     wanted to be able to refer to a great big block of prefix
> mappings, sometimes in
>     an external document, and this technique would allow that.
> Regards,
> Mark


Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Thursday, 20 December 2007 13:07:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:25 UTC