These are random comments on Section 2.1 of the current paper's working
draft, sent here for archival and for triggering further discussion.
- o -
- xslt over RDF/XML is always possible, it's just unberably hard and
error prone, due to the XSLT-unfriendly nature of RDF/XML.
- "conceptually wrong" is a little big too strong, use "conceptually
defective"? A great example is the fact that rdf:type="blah" can become
the element name, modelling this in XPath is extremely hard.
- the other problem with XSLT is the notion that it acts as a
transformation filter on a given infoset. In theory, this infoset could
be as big as the whole triple store model itself, in practice however,
due to the intrinsic nature of XSLT recursivity, it is ill suited for
'selection by filtering'.
- mention XQuery as a potential alternative to the above, but note that
it suffers from the same problems as XSLT.
- "potential irregularit, openness and use of different vocabularies"
this is not true. XSLT can cope with that too. The problem is not that
is the fact that we have graphs instead of trees and all existing
technologies work with trees, not graphs.
- Xenon, just like any transformation stage, is not necessarely bound to
a display paradigm. It is *possible* to be used in that regard (if there
was such a thing as a 'formatting object' equivalent for RDF) but it's
not a defect of its design.
- declarative approaches different from procedural approaches in the
fact that they don't change the structure of the existing infoset but
they augment it. Display properties are 'added' to the original model.
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------
Received on Mon Apr 25 2005 - 16:42:25 EDT