Re: RDFa and Web Directions North 2009

On Feb 16, 2009, at 10:32, Mark Birbeck wrote:

> I hope you'll forgive me for not replying to each of the points in
> your email in turn, but the bulk of it does seem to cover ground that
> has already been addressed.

That's a convenient way to dodge technical issues. :-)

In particular, have my points #9, #11 and #12 been addressed? If so, I  
haven't seen it. Could you please give me a pointer?

> (You still seem to insist that somehow
> there must be a code fork if we want to have script that runs in both
> HTML and XHTML DOMs, yet three people have now explained that there is
> no need for one.)

See my points #6 and #7.

> The first is that whether 'URIs as identifiers' are an "annoyance", or
> the fundamental architecture of RDF needs revising, I can only say
> that with respect, you need to lighten up a bit; it may surprise you
> to learn that many things you don't like, or cannot see a use for,
> have enormous communities based around them and are daily solving
> serious problems. No-one is asking you to like them, but don't assume
> that just because something doesn't fit with your world-view, there is
> no value in what has been done.

If using full URIs is not a problem/annoyance for the RDF community,  
surely CURIEs are unnecessary and can be phased out.

> The second is that you say that if I "wish to get new features added
> to HTML5", I need to do this or that; I would like to clarify that
> whether HTML5 supports RDFa is neither here nor there to me. (You'll
> notice that I only joined this debate to clarify a point about
> processing.)

There are others who do care about making the HTML 5 spec explicitly  
include RDFa.

> This is because, provided that HTML5 doesn't break the DOM, i.e., the
> JavaScript interfaces are backwards compatible, then RDFa is *already
> in* -- by usage rather than by standard.

Including generating RDFa from script? Without different code paths  
for HTML and XML? In a way that serializes as XML successfully?  
Without having to use NS flavor of methods for setting but non-NS  
flavor of methods for getting?

> But since RDFa is just a bunch of attributes, and incorporating them
> into any document is straightforward, I personally don't have any
> problem with that.

I think this line of argument is disingenuous--particularly as a reply  
to an email explaining why it isn't that simple. (See in particular my  
points 9 though 13.)

It would be that simple if the attributes took full URIs as values and  
didn't depend on the namespace mapping context.

(Numbered points included below for reference.)
>> 1) Content consumer software should work both with HTML (text/html)  
>> and
>> XHTML (application/xhtml+xml) if it works with one of them.
>>
>> 2) For sane *software* architecture, code above the HTML/XML  
>> parsing layer
>> should be able to run its dispatch code without any conditional  
>> branches on
>> the HTMLness or XMLness of the origin of the data it is operating  
>> on. This
>> applies to native browser code, JavaScript code running in a  
>> browser and
>> non-browser (X)HTML consumers. (Even easy-looking tiny variations  
>> add up.)
>>
>> 3) The point above is not about abstract XML architecture. It is an  
>> actual
>> way of implementing software including (but not limited to) Gecko,  
>> WebKit,
>> Presto (as far as can be guessed without seeing the code) and  
>> Validator.nu.
>> Furthermore, the dominant design
>> (http://en.wikipedia.org/wiki/Dominant_Design) of HTML5 parsers for
>> non-browser applications is that they expose an XML API so that the
>> application-level code is written as if working with an XML parser  
>> parsing
>> an equivalent XHTML5 file.
>>
>> 4) The qname is an artifact of the Namespaces in XML layer in XML and
>> should not be significant to the application. The correct way to do
>> namespace-wise correct dispatch is to dispatch on the  
>> [namespace,local]
>> pair. If you are inspecting the qname of an attribute or element  
>> for any
>> reason other than round-tripping serialization, you are Doing it  
>> Wrong.
>>
>> 5) Given the points above, you should also do dispatch on the
>> [namespace,local] pair on the HTML side.
>>
>> 6) All features going into HTML5 should be robust and sane under  
>> scripting
>> even if the people proposing the feature where interested in read- 
>> only use
>> case is outside browsers. This includes keeping script-generated DOMs
>> serializable.
>>
>> 7) If, in order to satisfy point #2 above, your feature requires  
>> using
>> getAttribute (without NS) on getting but setAttributeNS (with NS)  
>> on setting
>> (to keep the XML DOM serializable!), your feature isn't satisfying  
>> point #6.
>>
>> 8) So far, experience shows that even violations all of the above  
>> points
>> that look small--such as lang vs. xml:lang--are more hurtful than  
>> people
>> imagine at first. Examples:
>> a) Browsers need to inspect two attributes instead of one to  
>> discover the
>> language.
>> b) To abstract problem a) away in non-browser applications in
>> high-performance (in terms of CPU instructions executed per  
>> application-made
>> query for an attribute) manner, the static RAM footprint of the  
>> Validator.nu
>> HTML Parser is bloated by pointer size times 2328!
>> c) The lang & xml:lang part of the HTML5 spec has had the highest  
>> incidence
>> of validator bugs per spec sentence. (Bugs are bad and costly.)
>> Hence, all violations all the above points should be taken very  
>> seriously
>> even if in isolation on their face the violations seemed  
>> ridiculously small
>> to be indignant about. Violations for xml:lang legacy are somewhat
>> excusable. Introducing new violations isn't.
>>
>> 9) If you are defining something in terms all of the namespace  
>> mapping
>> context, but you can't use DOM Level 3 lookupPrefix() to implement it
>> (without violationg point #2), you are Doing it Wrong.
>>
>> 10) Browsers aren't the only kind of Web content consumer software.  
>> What you
>> are specifying should work with XML API environments other than the  
>> browser
>> flavor of DOM.
>>
>> 11) SAX2--arguable the most correct and complete XML API there is-- 
>> when run
>> in the Namespace-aware mode (i.e. the correct mode considering  
>> contemporary
>> XML architecture) doesn't expose the namespace declarations as  
>> attributes.
>> Therefore, a SAX2-based RDFa-in-XHTML consumer needs to use the
>> non-attribute abstraction (startPrefixMapping()) for gathering the  
>> namespace
>> mapping context. However, the same application-level code (see  
>> point #2)
>> wouldn't work with an HTML5 parser that implements mapping from  
>> text/html to
>> SAX2 as defined today in the HTML 5 draft and as sufficient for all  
>> the
>> HTML5 features drafted so far.
>>
>> 12) XOM--arguable the most correct of the well-known XML tree APIs  
>> for
>> Java--doesn't expose the namespace declarations as attributes.  
>> Therefore, a
>> XOM-based RDFa-in-XHTML consumer needs to use the non-attribute  
>> abstraction
>> for using the namespace mapping context. However, the same  
>> application-level
>> code (see point #2) wouldn't work with an HTML5 parser that  
>> implements
>> mapping from text/html to XOM as defined today in the HTML 5 draft  
>> and as
>> sufficient for all the HTML5 features drafted so far. (XOM even  
>> disallows
>> including attributes names xmlns:foo in the tree.)
>>
>> 13) If points 9 through 12 were addressed by changing HTML5 parsers  
>> to
>> expose attributes called xmlns:foo as namespace mapping context,  
>> the change
>> HTML5 to enable RDFa would be notably more complex than just adding  
>> a few
>> attributes.
>>

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

Received on Monday, 16 February 2009 09:57:23 UTC