HTML+RDFa 1.1 editorial changes submitted by Alex Milowski

Alex,

All of your editorial feedback has been condensed into this e-mail. I
believe that all of your concerns have been either fixed or responded to
below, but please let me know if I missed anything.

> It would be really much easier to refer to the modifications listed 
> in section 3.1 if they were numbered or labeled somehow.  For my 
> purposes, a simple number list would suffice.

Done.

>> if no IRI is provided by a resource attribute (e.g., @about, @href,
>> @resource, or @src), then first check to see if the element is the
>> head or body element. If it is, then set new subject to parent
>> object."
> 
> but step 5 has two parts.  It is unclear how each part is modified:
> 
> 1. Do you all mean that the new subject is only set if the element is
> 'head' or 'body'?

No, what we're trying to convey is that if @about, @href, @resource, or
@src don't exist on the HEAD or BODY element, then 'new subject' should
be set to 'parent object'.

> 2. In 5.1 and 5.2, the final default for the new subject is the value
> of the parent object. Also, for step 6, the default is already the
> parent object.

Hmm, I think you're correct. We did make some changes to RDFa Core that
made this alignment. I vaguely remember thinking that I'd remove the
language if we made the alignment, but then probably forgot to remove
the language. That said, I also remember thinking I could remove the
language and then finding out that there was a corner case where this
was not possible.

For example, for step 5.1, what happens with this markup?
<head typeof="http://schema.org/WebPage"> ? I think this triple is created:

_:bnode1 rdf:type schema:WebPage .

When I thought what we intended was this:

<> rdf:type schema:WebPage

It seems like we should have this in step 5.1 as well?

"otherwise, set the typed resource to the value of new subject." before
we try to create a new bnode in step 5.1

We'll discuss this on the call this week, and remove the text if the WG
agrees. It seems like the text is unnecessary, but that there might be a
bug in step 5.1.

> 2. You all should add a reference to the [@datetime attribute in the 
> HTML5] spec [1].

Done, but with the caveat that Gregg elaborated upon in his response to
you. We don't strictly follow the HTML5 content model because it would
complicate processing without having a very strong upside.

> 3. Is it the case that there is a deterministic algorithm for 
> property detecting the type from the possible set of values and 
> non-values?

I agree with Gregg. A good bit of effort went into this particular
section of text in the specification (most of the RDFa WG members
wordsmithed that text). It is correct. :)

> It just feels like [HTML Literals] should be there in [RDFa Core] 
> regardless of whether or not the host language can actually support 
> it.

I agree. We do not have the authority to change the RDFa Core
specification with a normative change of that magnitude at this point in
time. I've recorded your request for a future RDFa Working Group:

https://www.w3.org/2010/02/rdfa/track/issues/149

> The property copying "feature" of the HTML+RDFa 1.1 specification 
> feels to me like it is in the wrong place.  It should be part of the
>  core for RDFa.

Agreed, but we can't make that sort of non-normative change now (see
above). I opened an issue for it:

https://www.w3.org/2010/02/rdfa/track/issues/150

> It's actually pretty simple to do, and I believe Manu has an 
> efficient implementation in his streaming processor.

In an alternate universe where I have unlimited time, my processor has
that feature fully implemented. In our reality, I worked through enough
of the details in my head to feel positive that it's fairly trivial to
implement in a streaming processor.  You basically have to remember the
rdfa:copy and rdfa:Pattern triples (and associated subjects and
objects). Then at the end, you do the post-processing. This has a
down-side of spitting out spurious rdfa:copy triples, so I was going to
add a flag to the processor to do the "right" thing and hold all triples
until the document has finished processing and do the proper cleanup on
the output graph. The downside being that memory usage takes a huge hit
when you do that. It'll be a runtime flag, so the developer can decide
if they really want to clear out the rdfa:Pattern and rdfa:copy
statements from the graph.

Ok, I think those are all of your comments. The changes should be
visible here:

http://www.w3.org/2010/02/rdfa/sources/rdfa-in-html/Overview-src.html

Let me know if I missed something.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Tuesday, 28 May 2013 01:59:11 UTC