Re: FPWD Review Request: HTML+RDFa

On Sep 4, 2009, at 12:42, Mark Birbeck wrote:

> On Thu, Sep 3, 2009 at 2:25 PM, Henri Sivonen<hsivonen@iki.fi> wrote:
>> On Sep 3, 2009, at 15:06, Anne van Kesteren wrote:
>>
>>> Treating xmlns as any other attribute seems like a violation of the
>>> architecture of Namespaces in XML to me. I.e. a layering violation.
>>
>>
>> Indeed, namespace declarations in XML don't appear in the  
>> [attributes]
>> property of an element information item in the Infoset. They appear  
>> in the
>> [namespace attributes] property and also affect the [in-scope  
>> namespaces]
>> property.
>>
>> See http://www.w3.org/TR/xml-infoset/#infoitem.element
>
> Sure.
>
> But that's not the DOM, which is what everyone seemed to be talking
> about before.

I can't speak for everyone, but I have spoken, over and over again,  
not only about the DOM but also about SAX, XOM, browser-internal APIs  
and whatever namespace-aware XML APIs there are out there.

> The original objection was that different processing is required for
> different DOMs, and I think we've shown that's not the case;

I'm talking about Level 2 and later. You are talking about Level 1.  
Level 1 is inappropriate for namespace-correct application development.

>> It's highly unusual at the W3C to layer a spec (other than  
>> Namespaces itself
>> of course) directly on top of XML 1.0 instead of layering it on top  
>> of XML +
>> Namespaces (or the Infoset).
>
> But the thing is, RDFa doesn't actually _use_ namespaces.

Did you make this point clear to the TAG during the review period  
before RDFa in XHTML was promoted to REC?

On Sep 4, 2009, at 13:33, Mark Birbeck wrote:

> I understand what you are saying about the seven predefined namespace
> mappings, and that you perceive RDFa will require the provision of a a
> generic way to get at all namespace mappings.
>
> But as I've said in another thread, even if you went to the trouble of
> adding such a feature, an RDFa parser isn't going to thank you for it.
>
> An RDFa parser needs only DOM Level 1 support -- i.e., the ability to
> iterate a list of attributes, and the ability to get an attribute's
> value, by name.

What do you propose doing with APIs that properly reflect the Infoset,  
such as XOM?

Taking the Namespaces layer out of the data model is a problem when  
there's already so much software that has been written with Namespaces/ 
Infoset-correctness in mind.

Hiding the xmlns syntax in the text/html parsing algorithm is much  
easier than to purge the Namespaces-compliant data model from software  
and specs (such as RELAX NG) created during the last ten years or so.

> Sure, that would be nice, but neither DOM1 nor DOM2 supports such a
> feature, so it seems pointless for us to define the RDFa parsing
> algorithm in terms of that. And consequently, there's no reason that
> the HTML5 DOM should provide such a feature just for RDFa, if no other
> DOM is going to do so.
>
> The second feature would be to indicate which mappings are 'in scope'
> (although without the first feature, I don't know how we'd get hold of
> them...).

FWIW, DOM Level 3 has lookupNamespaceURI(), although it's definition  
is bogotic when considered in the context of synthetic DOMs.

> That might seem handy, but it would actually be completely redundant;
> the RDFa parsing algorithm takes care of 'in-scope' mappings itself,
> and takes them with it as it moves up and down the DOM, pushing and
> popping as it goes. Since there are other things that need to be
> tracked too, then there is little an RDFa parser would gain from such
> a feature.
>
> I should point out that the reason the algorithm was written this way
> -- rather than saying "get current in-scope XML namespaces" -- was to
> allow for other ways of providing prefix mappings, such as the @token
> and @prefix proposals. By tracking the scope in the parser, we can
> effectively use any attribute to indicate mappings.
>
> So as I say, there really is nothing 'special' that an RDFa parser
> needs from an HTML5 DOM, and I certainly don't want you to be
> concerned that RDFa requires changes to the HTML5 DOM.

And if you are working on top of infrastructure that doesn't give you  
an XML 1.0 view but only an Infoset view? How do you interleave non- 
xmlns scopes and prefix mappings processed for you by the  
infrastructure?

> It's a bit like saying that the algorithm to get the current  
> language is:
>
>  "retrieve a value from an attribute called 'x'"
>
> This algorithm is simple, so the only debate would be what 'x'  
> should be.

In the Infoset the things that were attributes on the XML 1.0 layer  
are no longer in [attributes] on the Infoset layer.

> Now, if we had chosen '@banana' to hold the language values, people
> would have rightly shouted and said "use @lang and @xml:lang" because
> they are already being widely used. But the algorithm would have
> remained intact, whatever attribute name we had used.

@banana and @lang are similar in terms of the DOM.

As for using xml:lang, I've already in this very thread complained  
about your use of xml:lang by asking you to defer to the HTML5 rules  
for determining the language of a node.

> Again, the debate would be about what should we use for 'x', and we
> felt that for the first version of RDFa, we would have had trouble if
> we didn't use the @xmlns:* syntax.

It seems to me that you should have predicted some kind of "trouble"  
either way. In retrospect, I'd have preferred you taking the political  
heat for not using xmlns than the technical trouble of using it.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 4 September 2009 11:54:50 UTC