W3C home > Mailing lists > Public > public-rdfa@w3.org > March 2015

Re: <iframe@srcdoc> property value

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Sun, 29 Mar 2015 18:39:27 -0700
Cc: public-rdfa <public-rdfa@w3.org>
Message-Id: <F49C933A-311B-40D9-A639-AEE5583385FB@greggkellogg.net>
To: Andrea Rendine <master.skywalker.88@gmail.com>
> On Mar 27, 2015, at 10:44 AM, Andrea Rendine <master.skywalker.88@gmail.com> wrote:
> 
> Greetings to all.
> I had this idea some days ago, while discussing with Ivan Herman about the possibility of processing an attribute for RDFa. However, that subject was unrelated to this proposal.
> 
> Long time ago I asked WHATWG about how to semantically mark up stuff in an <iframe@srcdoc> scenario. Namely, I requested whether semantic markup parsers are required to extract data from elements inside @srcdoc document fragment, and therefore to parse @srcdoc content. The fact is, @srcdoc content is something that, once parsed (with entity conversion), resembles markup and is to be treated as a document fragment. But in order for this to work, a user agent must know the subtleties of such an attribute.
> 
> I received no answer for that, but still I realised that it was pointless because markup *inside* @srcdoc has no meaning on its own. Rather, all the content of @srcdoc can be relevant as an object (a comment, a review, an external integration to an article, etc.). In this case, I guess that an RDFa property specified on an <iframe> should refer to that content in first analysis, and treat @srcdoc value as it would with a property with value identified as XMLmarkup-typed literal (datatype="rdf:XMLLiteral").
> This would be useful in all cases where @srcdoc matters, and even more useful for fans of RDFa Lite (as I am), who choose not to use @datatipe and therefore can never benefit from identifying content and markup as property value. Finally, it's perfectly backward compatible as authors who use @srcdoc are suggested to use @src for legacy compatibility, while the former always takes precedence over the latter. The rule would be the same for HTML and RDFa: the parser should consider @srcdoc as property value if compatible, otherwise it would use @src.
> Is this viable?

Hi Andrea. Just my opinion, but RDFa rarely gets into the semantics of the markup languages, and typically only deals with specific attributes (@about, @resource, @property, @rel, etc.). There are some HTML provisions for @href, @src, @rel and @rev, but typically these just map to something like the core properties.

One place we did stray was to parse the value of @datetime for content, or of the value of a time element, which is not too different from your scenario. There is also discussion about interpreting @data as a numeric value, so between @datetime and @data, it is possible to get many datatyped literals.

While a processor might look at the content of @srcdoc as you suggest, XMLLiteral is not very popular; an rdf:HTML literal is more palatable, but I think for this to be taken up would need to see some usage of this in the wild.

So, in short, while what you suggest seems technically feasible, it will require some support among both tool writers and authors. I’m personally not wild about it, and there’s no WG that can do anything formally, but a community consensus could make this possible, just not likely, IMHO.

Gregg

> Thank you for your patience
> Andrea Rendine
Received on Monday, 30 March 2015 01:39:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:55 UTC