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

This was my immediate reaction as well.  I don't think we can say that 
the processing model works this way in an XML world.  We would be better 
off just saying that some special prefix definition syntax has document 
scope.

Sorry.

Ivan Herman wrote:
> 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:-)
>
> Ivan
>
> 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
>>
>>     
>
>   

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Thursday, 20 December 2007 13:13:26 UTC