Re: Review of "Storing Data in Documents"

On Tue, 2005-03-22 at 14:47 -0500, noah_mendelsohn@us.ibm.com wrote:
> Dan Connolly writes:
> 
> > I have thought of it as implicit in the spec too,
> > but it's clearly too implicit. I hope to clarify
> > soon...
> 
> > There's a relevant section... in the editor's
> > draft, at least...
> >   http://www.w3.org/2004/01/rdxh/spec#ns-bind
> 
> Cool!  Am I right in suggesting that this is in part making good on the 
> promise of Cambridge Communiqué 

I think so... 


> Actually, the Communiqué focussed quite a bit on putting the mapping hooks 
> into the XML Schema for a namespace, and that seems to be exactly what's 
> shown at [2].  So, it took 5 years, big deal!

:)

Aside from the time... it also involved going from a declarative mapping
to a turing-complete (procedural) solution, which isn't ideal, so the
declarative approaches should still be persued, or at least discussed.

>   Maybe Dan's historical 
> review at [3] should mention the Communiqué, the hooks left in the XML 
> schema design, and the exploitation of those hooks by GRDDL?

I'm running out of office time today, so I just added
a @@TODO to discuss the connection in
$Revision: 1.15 $ of $Date: 2005/03/22 23:56:16 $ by $Author: connolly $
http://www.w3.org/2004/01/rdxh/specbg.html


> On a barely related subject:  I'm tempted to ask how central the .xsl 
> document really should be in defining the transformation.  On the one 
> hand, it obviously is.  On the other, it seems to me that XSL is in some 
> ways too high overhead to use in some of the higher performance situations 
> where you'll want to do these mappings.  Try to import 100,000 XML 
> documents into and RDF database;  running XSL 100,000 times isn't going to 
> help if all you're doing is extracting some simple metadata about authors 
> and creation dates.
> 
> What I'm struggling to articulate is whether there should be some sense 
> that the URI in the GRDDL should be for the transformation in the 
> abstract, with the xsl viewed just as a representation of that 
> transformation.

Indeed, that's the way it's specified:

[[
Transformation algorithms should be represented in XSLT[XSLT1, XSLT2].
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. Other representations may be used by prior agreement of
all concerned parties.
]]
 -- http://www.w3.org/2004/01/rdxh/spec


>   Thus, we might emphasis that it's not running the .xsl 
> per-se that's mandated by GRDDL, but implementating the correct transform. 

Right; that's especially true in the case of well-known transformations,
to address security as well as performance issues... darn; I thought
I discussed that somewhere, but I don't see it...

>  I don't know whether there are observable differences in these two views, 
> but I think the philosphical implications are somewhat different.  For 
> example, I could invent a transform URI and document it in English or 
> French.  You or I could write C code to implement the transform.  Maybe or 
> maybe not someone would go to the trouble of offering an XSL 
> representation of the transform, retrievable at the URI, as well.  This 
> idea seems closely related to but not quite the same as the Standard GRDDL 
> library mentioned in Dan's note.  Does this make any sense? 

Quite.


> Anyway, now that I've finally grok'd GRDDL, it looks like really nice, and 
> more to the point, I like Dan's note at [3].

Thanks!

> Noah
> 
> [1] http://www.w3.org/TR/1999/NOTE-schema-arch-19991007#observations
> [2] http://www.w3.org/2003/g/po-ex
> [3] http://www.w3.org/2004/01/rdxh/specbg.html

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Wednesday, 23 March 2005 00:02:27 UTC