- From: Nathan <nathan@webr3.org>
- Date: Thu, 05 Aug 2010 13:52:53 +0100
- To: Mark Birbeck <mark.birbeck@webbackplane.com>
- CC: Toby Inkster <tai@g5n.co.uk>, Manu Sporny <msporny@digitalbazaar.com>, Ivan Herman <ivan@w3.org>, W3C RDFa WG <public-rdfa-wg@w3.org>
Mark Birbeck wrote: > > So, in my view there are many use-cases for getting back the DOM node, Agreed, Manu followed up with a v similar response and I certainly see & have the need myself - again if I may nudge your attention towards http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Aug/0017.html particularly: [[ 3: Would a simple method on the document to return elements by filtering not suffice document.getElementsByFilter( subject, predicate, object ); where each param is optional and where at least one is required. or document.getElementByTriple( RDFTriple triple ); again where 1 or more properties of the triple would need to be set. ]] > Anyway, to sum up...my vote is for the DOM node to only be provided as > part of the projection routines, and not with every single part of a > triple. If we find we need more than one DOM node in a projection then > we can certainly look at that, but that's separate -- by limiting the > DOM node to projections we are able to leave the objects for IRI, > literal, triple, and so on as 'clean' as possible. Certainly +1 to the approach of only having the DOM node where needed, and not on IRI through Triple, makes sense every way I look at it. Still remain unconvinced by projections, yet realise they do provide a workable approach, and given the aforementioned keep the rest workable too - i.e. could work with that :) Best, Nathan
Received on Thursday, 5 August 2010 12:53:58 UTC