Re: Meaning and priority of standard XHTML properties

Comments inline...

Mark Birbeck wrote:
>
> Hi Shane,
>
> I think you are right.
Well - you *think* you think I am right.  Just wait.
>
> However, there is a sort of 'principle' that I have been working to in
> my mental model of RDFa and its relationship to the DOM, which is that
> an RDFa processor actually adds the properties to the DOM as it
> parses. I mentioned this on one of the SWBP telecons a while ago, and
> it turns out that Ben has also been thinking along the same lines, and
> that's subsequently how he has implemented his Firefox plug-in, which
> shows it can work.
Its great that as a proof of concept you can do this, but we do not 
mandate an RDFa processor.  Moreover, changing my DOM in this way would 
violate the principle of least surprise.  That means, if I am attempting 
to develop portable web content, I cannot rely upon these features at 
all.  Since one of our goals is to promote the use of these technologies 
sooner rather than later, we might want to err on the side of backward 
compatibility to the extent possible; this will make it more likely 
people will develop content today that works in existing browsers but 
ALSO has magically RDF-able metadata.  At least, I think that is the goal.
> So in this approach you don't need the findMeta() method, since the
> metadata is there in the DOM for you to get. (You might add a SPARQL
> query processor...but that's another story!) This seems to me to put
> the onus on the RDFa processor to do the work--and what's more this
> whole thing can easily be done in script.
>
> It also means that the following two statements are equivalent in UAs
> that support RDFa:
>
>  <div role="wai:toolbar">
>    ...
>  </div>
>
>  <div>
>    <link rel="role" href="[wai:toolbar]" />
>  </div>
Yes, but so is:

<head>
  <link about="#toolbar" rel="role" href="[wai:toolbar]" />
  ...
</head>
<body>
...
<div id="toolbar">
...
</div>
</body>

And that is not proximal...  and it doesn't say what happens if I do:

<head>
  <link about="#toolbar" rel="role" href="[wai:toolbar]" />
  <meta about="#toolbar" property="title">
      this is my title
  </meta>
  ...
</head>
<body>
...
<div id="toolbar" title="this is my proximal toolbar" role="contents">
   <link about="#toolbar" rel="role" href="[insanity:navbar]" />
...
</div>
</body>

This way lies madness...  however, your point is well taken.  We can't 
just get rid of the colliding "title" property and attribute by changing 
its name to bagel.  I had forgotten about link and its ability to 
collide as well.  So we need to define precedence rules.
> Now...of course this is all completely absent from the spec! But I'm
> not completely sure that it should be in there yet anyway--even if we
> agree on this approach--since we don't talk of the DOM in XHTML 2
> anyway, do we? So I would think that XHTML 2 is ok for now, and we
> could probably get away with simply saying that there is an
> 'equivalence' between the two syntaxes, and then leave it to some
> DOM-related spec to spell out what that means at the DOM level.
I disagree.  We cannot let the DOM sort it out because 1) there is no 
DOM working group per se, and 2) we are the ones who made this mess.  
The DOM is just a manifestation of our rules, not vice versa.  It is 
incumbent upon us to define those rules.  If the working group believes 
things are equivalent.... we need to explicitly state that.  However, in 
the interests of our primary audience (web developers) I would suggest 
we try something less disruptive:

   1. Permit all of the historical XHTML usage that our customers expect.
   2. Define that certain historic XHTML concepts are interpreted in
      specific ways when evaluated for RDF triples (role, title, whatever).
   3. Define how meta and link are used to define triples that relate to
      the rest of the XHTML document (we already do this).
   4. Require that with respect to RDF, where RDF properties overlap
      with XHTML attributes, an attribute on an element takes precedence
      over annotation that is elsewhere in the document.
   5. Permit, but not require, user agents to interpret annotations as
      their corresponding XHTML attribute iff (if and only if) there is
      no similar attribute value specified on the target element. 
      However, require that even if this is the case it is NOT
      manifested in the DOM in a way that could be interpreted as if the
      XHTML element really had that attribute value defined.
   6. Define (of ask someone else to define) a DOM method that will ease
      the search for annotations for those portable applications that
      need it.

This approach has the advantage of being pseudo-backward compatible, 
RDF-friendly, and allows innovative browser developers to take advantage 
of the annotations if you have content developers who want to go to the 
trouble. 

REMEMBER: the primary motivator behind RDFa and supporting RDF concepts 
in XHTML is NOT to support this type of document internal annotation.  
It is to help define the semantics for content with properties like 
those from Dublin Core.  The behavior we are discussing here is a happy 
consequence of this support.  We do NOT need to attempt to turn XHTML 
and/or the DOM on its head in order to support something that we ALREADY 
support quite handily (internationalization of title attributes not 
withstanding).

The obvious question is:  What am I missing here?
>
> What do you think?
>
> All the best,
>
> Mark
>
> On 15/06/06, Shane McCarron <shane@aptest.com> wrote:
>>
>> Actually, there is more to it than this.  I appreciate that what we are
>> saying is that the meta element allows the specification of certain
>> metadata properties about the document or about segments of the
>> document.  However, this is completely separate from the setting of
>> XHTML attribute values.  The fact that there is a title attribute on
>> every element, and that there is also a potential title metadata
>> property, is no doubt intentional.  But I do not think that we can
>> require that XHTML conforming user agents somehow overlay that property
>> onto the attribute value....
>>
>> It is fine to require that the attribute value be interpreted as an RDF
>> predicate, since that is specialized processing.  The RDF-ness of XHTML
>> is a happy side effect that can be derived by RDF-aware agents.  It is
>> not something that I think we are mandating be available in every user
>> agent.
>>
>> So, what am I driving at here?  It comes down to the XML DOM.  If I am
>> relying upon that DOM and its structure to find information about a
>> document, and I want to know the title associated with an element, I am
>> going to look at the value of the title attribute.  I am NOT going to
>> hunt around for random meta elements that are children of that element.
>> I am surely NOT going to look for meta elements anywhere in the document
>> that might have an about attribute that references my target.  That
>> would be insane.
>>
>> My proposal here is simple but potentially destabilizing:  Change the
>> property attribute value "title" to something else.  Decouple that
>> particular piece of metadata from the markup.  For now, I will call it
>> "bagel".  If we like, we *could* say that when processing XHTML
>> documents using RDF aware parsers, a triple is *also* formed based upon
>> the title attribute of an element, if any.  That would at least garner a
>> lot of fun metadata for free (every href with a title has some
>> semantics).  But if we just decouple these then there will be no
>> confusion and no expectation that the DOM does anything to attempt to
>> propagate these "properties" into the corresponding attribute values.
>>
>> In addition, I recommend we design a DOM extension (optional DOM
>> feature?) that allows me to explicitly search for this type of
>> metadata.  document.findMeta(idref, propertyName) or something.  At
>> least then I would know if I had some portable way to try and find this
>> stuff.  Otherwise, I think we are violating the principle of least
>> surprise - and that is never good.
>>
>> Steven Pemberton wrote:
>> >
>> > We have said in XHTML2 that things like
>> >
>> >     <a title="gezellig" href="gezellig.html">gezellig</a>
>> >
>> > is equivalent to
>> >
>> >     <a href="gezellig.html">
>> >         <meta property="title" content="gezellig"/>
>> >           gezellig
>> >       </a>
>> >
>> > The question has arisen, what happens with:
>> >
>> >     <a title="Peioria" href="gezellig.html">
>> >         <meta property="title" content="gezellig"/>
>> >           gezellig
>> >       </a>
>> >
>> > From an RDF point of view, there's no problem (the element has two
>> > titles) but what should a browser do with respect to, for instance,
>> > tool tips?
>> >
>> > Steven
>> >
>>
>> -- 
>> Shane P. McCarron                          Phone: +1 763 786-8160 x120
>> Managing Director                            Fax: +1 763 786-8180
>> ApTest Minnesota                            Inet: shane@aptest.com
>>
>>
>>
>>
>>
>
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Thursday, 15 June 2006 14:47:56 UTC