Pointing out content for properties

Greetings to everybody.

I wrote to this mailing list some time ago, with the proposal of
integrating <iframe@srcdoc> and <data@value> into RDFa mapping model.
This would allow RDFa processors to read these attribute as property
content, instead of the default behaviour (@src and content
respectively). The first case was not so common, while for the second
I was offered a deep insight of the real issues for such a scenario by
Manu Sporny himself.

Essentially, as RDFa is not meant for HTML only, but for a variety of
languages, it would be a bad choice to support a myriad of specific
cases for specific elements in specific languages. The problem with
<data@value> is also that the value attribute is used in several
elements (e.g. <li> in ordered lists, form controls), so the
interpreter should be integrated with the rule "read the value
attribute in the data element, but not anywhere else". Consistency is
greeting from afar, I know.

RDFa is sensitive to the subject of specific content, in fact it is
possible to specify that the content of a property should not be the
text node concat, but the markup as a whole
(datatype="rdf:XMLLiteral") or an entirely different string
(content="alternative content").

The problem is, in the latter case the alternative content is already
there, hidden in other attributes which can have a semantic on their
own. This is true for both HTML and XML. And RDFa cannot know it in
advance. XML can have the strangest element/attribute assets, while in
HTML WG there's a small but growing voice about custom elements. In
addition to this, sometimes the choice of considering content instead
of attributes could be ambiguous.

I don't know whether there still is a RDFa WG, but in case there is a
project for future versions, this is my proposal:

A new attribute could be defined in RDFa. It should be in the "Lite"
flavour of the language, so that it could be used in the core version
as well. This attribute, let's call it "context", could specify which
part of the DOM defines the @property content, also overriding
default. This could also absorb the case where not only the plain
literal text content is to be considered, but the whole xml/html
subtree:
 - <data property="amount" context="attr(value)"
value="-1234">(1,234)</data> this defines the content of @value as
reference value for amount, instead of text content (where the
negative number is represented in a sector-specific notation and with
a local K separator)
 - <a property="fullName" context="content(text)"
href="/profiles/foo_mcbar">Foo McBar</a> tells the interpreter to look
at the text content of the <a> element instead of considering the
external resource(note: this can be currently achieved in other ways,
such as <a href="/profiles/foo_mcbar"><span property="fullName">Foo
McBar</span></a> and it's just an example)
 - <div property="performance"
context="content(XML)"><table><tr><th>2014</th><th>2015</th></tr><tr><td>+100</td><td>-200</td></tr></table></div>
instructs the interpreter to consider the whole table as content for
"performance" property.
 - without the context attribute, the default behaviour applies (i.e.
take the resource if specified and the content otherwise).

This would make some situations easier to maintain and would allow the
semantic of HTML to be even more semantic, leaving authors deal with
use cases.

Is this possible to achieve? I hope to receive some feedback.

Andrea Rendine

Received on Monday, 19 September 2016 13:17:59 UTC