Re: ISSUE-147 (preserve markup by default): RDFa Processors should preserve markup by default [RDFa 1.1 in HTML5]

> If we were to do anything, it would only be for HTML5+RDFa, not XHTML1+RDFa or RDFa 1.1, as that ship has sailed. Furthermore, if this were to change for HTML5+RDFa, rdf:HTML would be a more appropriate datatype then rdf:XMLLiteral IMO.
>

Very much agreed that RDFa 1.1 is a REC so that ship may have sailed.
I raised the issue on RDFa 1.1. in HTML for that reason. I of course
would be happy if there were a procedural mechanism to re-raise it on
RDFa 1.1. Core.


 I am unsure of the status of rdf:HTML. I know of it from RDF 1.1 but
that's not yet a REC? Can we use it?

> Relating to 4), changing the rules now would be a major incompatibility with RDFa 1.1, which is explicit for this across all host language, so I think it's probably too late. The rules were changed when RDFa Core 1.1 became a REC, changing them back for HTML+RDFa would make it even more confusing.

You write "explicit for this across all host language". I don't see
this in spec. I do see Section C.1 [1] but I don't see that placing
any restriction on what can happen in the "RDFa in HTML" product. But
I could be wrong about that. Or maybe it's more explicit elsewhere?

[1] http://www.w3.org/TR/rdfa-syntax/#major-differences-with-rdfa-syntax-1.0

>
> This was resolved in May of 2010 [1]; it was also specifically called out in the charter for the RDF Web Applications Working Group [2].
>


I do think that this was wrongly resolved but I understand that may
not be relevant given that we are talking about the "RDFa in HTML"
product. I do note that there is an open issue to introduce @itemref,
which is also a substantial incompatibility with Core so that I don't
think that concern is enough to close the issue at this time.

 If the history of discussion about why RDFa Core 1.1 reached this
determination is relevant, here's a very short version of why I think
it was wrongly decided:

 @property values for properties as dc:title can be expected to have
meaningful markup. Take the case of titles that mix left-to-right and
right-to-left languages. See this web page [2] for the title of a that
does just that. The RTL language in this case is Syriac. Whether one
is using dc:title or dc:bibliographicCitation, in order to confidently
communicate the different languages in such a way that the information
is likely to persist in an RDF based toolchain, the RDFa processor
should preserve the well-document (X)HTML markup that communicates the
direction of texts.

 But maybe mixed Syriac/German/English titles seem obscure. I can
introduce titles that mix some combination of modern European
languages, Greek, Hebrew, Latin, Chinese, Japanese, and more if that
is useful. And as I write it does occur to me to also ask how embedded
SVG is handled? One of SVG's strengths is that it puts meaningful
content into attributes. Will all that disappear by default? I'll look
into that.

 Of course, there is the question, "Why not just use @datatype as RDFa
1.1. Core suggests?". I believe that's bad design. To take a sequence
of characters that is an XMLLiteral (or rdf:HTML) and change it by
default into a less rich representation puts a burden on authors of
unnecessarily repeating their intent. Unless there is a good reason to
discard markup, don't.

 But again, the focus of my comments is the "RDFa 1.1 in HTML"
product. I believe there is procedural room to have that deviate from
Core when a strong argument can be made. RDFa Core addresses generic
XML documents. When bringing it into the (X)HTML world it is no
surprise that adaptation need to be made.


[2] http://morephrem.com/bookshop/index.php?route=product/product&product_id=203

 -Sebastian

> Gregg
>
> [1] http://www.w3.org/2010/02/rdfa/meetings/2010-05-13#resolution_2
> [2] http://www.w3.org/2011/03/rdfwa-wg-charter

Received on Friday, 28 December 2012 21:37:29 UTC