- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 12 Feb 2007 13:07:47 -0600
- To: Danny Ayers <danny.ayers@gmail.com>
- Cc: Harry Halpin <hhalpin@ibiblio.org>, public-grddl-wg <public-grddl-wg@w3.org>
On Sun, 2007-02-11 at 22:01 +0100, Danny Ayers wrote: > re. http://www.w3.org/2004/01/rdxh/spec > Revision: 1.206 [...] CVS change summary is... Revision 1.208 2007/02/12 19:06:01 connolly move protocol trace from appendix to main body clarify "profile" to "metadata profile name" move XHTML rules after examples change R to N in some rules so that prose matches mechanical rules (which have been tested) wordsmith "any other programming language" and "XPath data model under-determined" bits (tx Danny A.) add todo on security considerations around multiplying requests Details follow... > 4. Using GRDDL with valid XHTML > > I'd be tempted to shift the "Stated more formally:" green boxes past > the first example - the informal paragraph is pretty confusing itself. OK, I moved it after the both examples. The result might be choppy. I'm not sure I have energy to wordsmith a transition just now. > The second & third green boxes - defining "profile" & "typed link" - > appear to be formalisations of part of a spec cited normatively, which > seems back-to-front - is a comment needed? Yes; I added one. > (HTML4 is pretty loose on > those point ;-) > > 5. GRDDL for HTML Profiles > > (seems ok apart from an @@ already marked) > > 6. Transformation Algorithms > [[ > Developers of transformations should make available representations in > widely-supported formats. > ]] > Doesn't sound right. Not sure why... > > [[ > While javascript, C, or any other programming language technically > expresses the relevant information, XSLT is specifically designed to > express XML to XML transformations and has some good safety > characteristics. > ]] > => > [[ > While technically Javascript, C, or virtually any other programming > language could be used to express transformations for GRDDL, XSLT is > specifically designed to express XML to XML transformations and has > some good safety characteristics. > ]] "could" suggests that this is counter-factual. I used "may". > If this is true, it should be bolder! The WG decided it's true in our 31 Jan decision on the faithful-infoset issue http://www.w3.org/2004/01/rdxh/spec#faithful-infoset -> http://lists.w3.org/Archives/Public/public-grddl-wg/2007Feb/att-0017/31-grddl-wg-minutes-edited.html#item02 > [[ > When an information resource is represented by an XML document, the > corresponding XPath data model is somewhat under-determined, depending > on, for example, whether an agent elaborates inclusions, parameter > entities, fixed and default attributes, or checks digital signatures. > ]] > => > [[ > When an information resource is represented by an XML document, the > corresponding XPath data model may not be fully determined, depending > on, for example, whether an agent elaborates inclusions, parameter > entities, fixed and default attributes, or checks digital signatures. > ]] OK. > This, and the material that follows "Put another way..." tends toward > the discursive/informative, should maybe be broken out into a separate > section, following the more normative material. I'm not inspired with anything better just now. > 7. Security considerations > > Seems ok, except the caching section isn't really relevant - break out > to an appendix: "Notes for Implementors"?? It's a bit of a stretch, but better to be conservative; Spreading expired data around is a security risk. Plus, there's more to say; I just added a todo... <p class="ed">@@TODO: dajobe points out that GRDDL turns a request for info from one page into several requests. Connect this to HTTP proxy security considerations.</p> > 7. (should be 8.) The GRDDL Vocabulary > > There's already an @@, looks like it's on DanC's plate - I assume an > RDF/XML version will follow... well, yes, an RDF/XML version is published as well as an XHTML version for http://www.w3.org/2003/g/data-view But the RDF/XML is generated via XSLT. Dave Beckett, Jeremy Carroll, and Henry and I are having a discussion of how GRDDL's own profile interacts with the grddl-for-xhtml-profiles mechanism. Resolving the @@ you note in section 5 will involve thinking about this a bit more. > 9. References > > Can this section be moved /after/ the appendices? I nearly overlooked > the content that follows it. Hmm... the spec should indeed stand without the appendices. I guess the protocol trace is too important to be an appendix. How about making it a section after security considerations: * GRDDL Transformations * Security Considerations * Example: A GRDDL-aware Agent protocol trace * The GRDDL Vocabulary * References > *** Appendix: A GRDDL-aware Agent protocol trace > > I like it ;-) > > Could a line be added saying which tools were used to create the trace? > (/me wonders if DanC favours telnet as a browser) OK... <p>HTTP trace data was collected via <a href="http://hathawaymix.org/Software/TCPWatch">TCPWatch</a> by Shane Hathaway. For more details, see <a href="http://www.w3.org/2001/sw/grddl-wg/td/testlist1#http_tracing">HTTP tracing in the GRDDL test materials</a>.</p> > *** Appendix: Transformations for Styling versus data extraction > > Can't say I like this as it stands in this position, but can't think > how to improve. > > *** Appendix: Issues > > - > > *** Appendix: Implementation Experience: Test Cases, Software, and Services > > Maybe move this together with any other related material into a "Note > for Implementors" appendix > > *** Acknowledgements and Change History > > - > > -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Monday, 12 February 2007 19:08:05 UTC