Re: <iframe@srcdoc> property value

Hi Mr Kellogg, thank your for the comprehensive answer.
As I was suggested to do, what I wanted to do with my message was to probe
RDFa users for consensus. If, and only if, this proposal is judged viable,
it will probably take some time to be translated into something practical.
I started this idea (along with <data@value>, and later simply @value; that
proposal is mine, too) in order to "respond" to the only strong point of
Microdata, i.e. how it is able to treat specific attributes, instead of
elements' content, according to the element it applies. Microdata, however,
is really too specific about what attributes are used and what context they
are fetched in (along with other liabilities).
If you want to hear something funny, I'm not such a big fan of @srcdoc. On
the contrary, I find its concept of treating attribute value as markup
quite messy. But that beast is over there right now. And it can serve a
better purpose IMHO, not now, but sooner or later. I suppose that first it
should be noted how often @srcdoc is really used. So we'll wait for next
compiled data lists from WebDevData.
Thank you very much for your answer, though!
Regards
Andrea Rendine

2015-03-30 3:39 GMT+02:00 Gregg Kellogg <gregg@greggkellogg.net>:

> > 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
>
>