Re: ISSUE-3 PROPOSAL: Infoset coercion

On 07/08/2010 09:43 AM, Ivan Herman wrote:
>> The concern isn't with XML Processors, since all the major ones
>> are Infoset-based and are thus namespace aware. All the ones used
>> by the browser manufacturers fit this model anyway - they're all
>> Infoset-based processors.
> 
> Ok, I understand (I think). But the text you refer to says:
> 
> [[[ If the XML API is namespace-aware, the tool must [...] when
> converting the non-XML mode DOM into an Infoset. Given a standard
> xmlns: definition[...] ]]]
> 
> So what you say is that all XML API is namespace aware, that we do
> not have to deal with non-namespace aware API-s. Is that correct?

All the XML APIs that we care about are namespace aware. Nobody has
asked us to deal with non-namespace aware XML APIs yet.

> (I
> used the term XML processor, my mistake, this is probably the same as
> XML API, right?)

Unfortunately, XML API is a term that I coined in that document to how
the developer accesses the Infoset. SAX is an example of an XML API.
Xerces is an example of an XML API.

Since it is possible to have an XML API that does not expose namespaces,
ie an XML Processor with an API that does not understand Namespaces in
XML[1], I'm going to get a bit pedantic.

An XML Processor and an XML API are different because:

An XML Processor builds the Infoset.
The XML API allows the developer to access that Infoset.

It is possible to have an XML Processor that is namespace-aware, but
does not expose the namespaces via the XML API. Therefore, an XML
Processor and an XML API are subtly different from one another.

The part that matters to an RDFa Processor and this discussion is
whether or not the developer can access the namespace tuples via the XML
API.

>> The concern is with non-XML processors, such as SGML-based
>> processors, which is the category that HTML5 non-XML mode falls
>> into. Non-XML mode processors are not namespace aware.
> 
> So where SGML-based processors come into the picture exactly? In
> browsers when parsing HTML5? Apologies for my ignorance...

Yes. Browsers that parse HTML documents using a non-XML mode HTML5
processor are in the class of SGML-based processors. I only say this
because they're certainly not in the class of XML-based processors in
that they're not strict about closing tags and tag order.

>> If HTML WG rejects the coercion to Infoset rule changes, we can
>> always fall back to defining how one extracts the namespace
>> information from a HTML5 non-XML mode document (for Infosets and
>> for DOM Level 2).
> 
> But... is this something that should go into the HTML WG?
> 
> What I mean is: what will a non-XML SGML parser do with
> xmlns:foo="bar"? I would expect that it would use an attribute with
> name "xmlns:foo" with value "bar". 

That is what the HTML5 spec currently says should happen, IIRC. Note
that the "xmlns:foo" attribute would be placed into no namespace, not
the "http://www.w3.org/2000/xmlns/" namespace.

> So the RDFa specification may very
> well define a mapping from this to our prefixes and CURIES,
> completely bypassing the notion of a namespace. That is in case the
> HTML5 WG does not want to accommodate...

That is correct, and the HTML+RDFa spec already does that (just in case
HTML WG rejects the coercion to Infoset rules):

http://www.w3.org/TR/2010/WD-rdfa-in-html-20100624/#infoset-based-processors

It also specifies how to extract mappings and interpret RDFa attributes
for DOM2-based RDFa processors:

http://www.w3.org/TR/2010/WD-rdfa-in-html-20100624/#dom-level-2-based-processors

So, I think our bases are covered.

> On the other hand... we already deprecate, in so many words, the
> usage of xmlns: for HTML5. So, in RDFa1.1 and SGML and non-XML and
> stuff we can just say: use @prefix... (I know, this is not 100%
> kosher, but just puts things in perspective...)

Yes, the introduction of @prefix has made this far less of an issue than
it was in the past.

-- manu

[1] http://www.w3.org/TR/xml-names11/

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Myth Busting Web Stacks - PHP is Faster Than You Think
http://blog.digitalbazaar.com/2010/06/12/myth-busting-php/2/

Received on Friday, 9 July 2010 03:45:38 UTC