- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 27 May 2013 21:58:37 -0400
- To: RDFa WG <public-rdfa-wg@w3.org>
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