- From: Sam Ruby <rubys@intertwingly.net>
- Date: Wed, 18 Feb 2009 09:51:11 -0500
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: Julian Reschke <julian.reschke@gmx.de>, Mark Birbeck <mark.birbeck@webbackplane.com>, Ben Adida <ben@adida.net>, Karl Dubost <karl@la-grange.net>, Kingsley Idehen <kidehen@openlinksw.com>, Dan Brickley <danbri@danbri.org>, Michael Bolger <michael@michaelbolger.net>, public-rdfa@w3.org, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, Tim Berners-Lee <timbl@w3.org>, Dan Connolly <connolly@w3.org>, Ian Hickson <ian@hixie.ch>
Henri Sivonen wrote:
> On Feb 18, 2009, at 16:15, Sam Ruby wrote:
>
>> Henri Sivonen wrote:
>>> While HTML5 parsing as defined today supplies namespace information
>>> for each element and attribute name, it doesn't supply
>>> xmlns:foo-based namespace mapping context for resolving prefixes in
>>> attribute content on the application layer.
>>
>> If you could put aside your understandable dislike for prefixes in any
>> form for a moment:
>>
>> How would renaming xmlns:foo="bar" to prefix="foo=bar" (or
>> whatever) address the issue you describe above?
>
> Case xmlns:foo="bar" gets the following treatment:
>
> With XML parsing and the XOM model, there is no attribute "xmlns:foo".
> That is, there'd be no arguments for getAttributeValue() (on an Element
> object) that would return "bar". However, getNamespaceURI("foo") would
> return "bar".
>
> With HTML parsing and the XOM model, getNamespaceURI("foo") would return
> null. Depending on parser configuration, there either would be nothing
> in the model corresponding to xmlns:foo="bar" or
> getAttributeValue("xmlnsU00003Afoo") would return "bar".
>
> Thus, the model would be inconsistent in the HTML and XHTML cases.
> (Unless HTML5 parsing is changed to accommodate RDFa.)
>
> Case prefix="foo=bar" would get the following treatment both for XML and
> HTML parsing:
> In XOM, getNamespaceURI("foo") would return null.
> getAttributeValue("prefix") would return "foo=bar".
>
> Hence, the model would be consistent in the HTML and XHTML cases without
> changes to HTML5 parsing.
>
> SAX2 would work in an analogous way.
XML is defined in terms of the W3C DOM. HTML5 is defined in terms of
the W3C DOM. Applications built only only W3C DOM interfaces can be
completely unaware of the differences between the HTML5 and XHTML5
serializations as long as they limit themselves to the non-NS-suffixed
APIs. Correct?
XOM and SAX2 are alternate mechanisms for accessing XML. I'm not aware
of HTML5 equivalents. But if there were equivalents for these two, it
is an open question as to whether such interfaces would behave the same
as if they were handing XML documents, or if they could be optimized
based on additional constraints on how attributes are used.
- Sam Ruby
Received on Wednesday, 18 February 2009 14:51:29 UTC