Re: Request to publish HTML+RDFa (draft 3) as FPWD

On Mon, Sep 21, 2009 at 9:00 PM, Shane McCarron <shane@aptest.com> wrote:
>
>
> Jonas Sicking wrote:
>>>
>>> Sure.  The rules for processing a source document are defined in the
>>> context
>>> of the host language. In this case, the HTML 5 specification indicates
>>> the
>>> rules for munging the input (I suppose).  RDFa doesn't care what the host
>>> language does with valid input (I am assuming the above is valid HTML5).
>>>  See the normative section 2 and informative seciton 2.1 of Manu's draft
>>> at
>>> http://html5.digitalbazaar.com/specs/rdfa.html
>>>
>>
>> But neither the HTML5 specification, nor Manu's draft, define a prefix
>> mapping algorithm for HTML documents. As far as I can see. I certainly
>> agree that one of those two needs to be the defining specification.
>>
>>
>
> Manu's draft refers to the RDFa Syntax Recommendation.  The RDFa Syntax
> Recommendation normatively refers to the *syntax* of the Namespaces in XML
> Recommendation.  That syntax defines the eBNF for prefix declarations.

But according to the syntax in the Namespaces in XML recommendation,
the <a> is a child of the <table>. My point is that Namespaces in XML
defines syntax for XML documents. HTML documents are processed very
differently from XML documents.

>> However the more important question was if attributes in the null
>> namespace can have any affect on RDFa processing. You seem to indicate
>> that being the case. I'm curious if you're basing that on a
>> specification, or if that's just how you think things *should* be
>> defined?
>>
>
> The later, I suppose.  The RDFa Syntax Recommendation defines the way in
> which source documents are mapped to triples.  There is *no* syntactic way
> to define two attributes with the same lexical name on the same element.

Even if there was only one attribute. Where does it say that the
attribute is honored even if it's in the null namespace? The
Namespaces in XML recommendation puts xmlns attributes in the
"http://www.w3.org/2000/xmlns/" so I don't see what spec says to honor
attributes in any other namespace?

>  You have posited a non-source way to manipulate the DOM so that there is an
> attribute in the XMLNS namespace and an attribute in the null namespace that
> have the same lexical "name".  I agree that it is possible to manipulate the
> tree so that such a thing could happen.  It is outside the scope of the RDFa
> Syntax Recommendation. I actually, personally, think it is academic and
> should be labeled "unspecified" if it is labeled at all.  But, since you
> asked, I suggested a way to handle the situation were it to occur on a given
> element.  I would be equally a happy to say "this is unspecified - it's a
> bad idea - don't do it... ever". Let me know which solution would best
> satisfy your concern.

If I understand you correctly, you seem to assume that the processing
model would be to serialize the DOM into an XML document, which can
then be interpreted using the Namespaces in XML recommendation? Is
this correct? If so, are you basing this on some specification or on
your opinion?

While this is certainly one solution, you have to deal with cases when
serializing the DOM to an XML document causes loss of data. Such as
when serializing a node with localName "xmlns:foo".

/ Jonas

Received on Tuesday, 22 September 2009 06:05:54 UTC