[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The limitations of XPath and navigation for XML databasepr

• From: "W. E. Perry" <wperry@f...>
• To: xml-dev@l...
• Date: Fri, 08 Feb 2008 13:03:08 -0500

Noah is right that there is a very deep problem here, and when Jonathan
says that "there's some weakness in [Michael David's] argument", I would
suggest that weakness is the stubborn insistence that, because XML (and
XPath) are fundamentally syntactic specifications, instances of XML and
XPath require some procedural pre-processing before they can be interpreted
as declarative. Michael David prefers SQL precisely because in SQL one is
manipulating semantic, not syntactic artifacts. He says as much in his
example:

> For example a Department hierarchical structure can be hierarchically joined with an Employee hierarchical structure and processed using hierarchical views as in
> SELECT Deptno, Empno FROM DeptView LEFT JOIN EmpView ON DeptID=EmpDeptID WHERE DeptNo=1204. This is a synergistic operation increasing
> the semantic value of the combined queried structure beyond each structure queried separately and it can be processed interactively.
>
That is, the data artifacts which Michael David is comfortable manipulating
have their particular semantics already established within the processing
context:  'Deptno', 'Empno', 'DeptView' and so on. His implicit assumption
is that only artifacts with such established semantics can truly be
manipulated declaratively. Because the artifacts of an XML (and therefore
XPath) instance are purely syntactic--the A, B and C of Noah's example are
simply character text--Michael David assumes that they require some,
effectively procedural, processing to elaborate from each of them the
particular semantics which truly allow them to be declarative artifacts. He
is not the first and certainly not the only one to be swayed by this
prejudice against syntactic artifacts as deficient for what he understands
as the semantics of declarative manipulation. I posted to this list on the
same point eight years ago
http://www.stylusstudio.com/xmldev/200003/post00380.html : "The fundamental
functions of an XML processor are syntactic. I am talking here about
processors more ambitious than parsers, which are simply plumbing, The
processor which I believe is described by that term in XML 1.0 takes XML
syntax as its input, and only expectation, and performs some fundamentally
local work
upon it. If that were not so, why would the document/data/message need to
be handled by that processor, or that node, at all? If the source of the
XML were obliged to share, and therefore to know, sufficient semantics to
be able perfectly to describe its intent to a separate processing node, why
not simply do the processing itself?" XPath is precisely such a post-parse
XML processor, and the deficiencies which Michael David sees in it are
precisely where I believe the strength of such fundamentally syntactic
processing lies.

Respectfully,

Walter Perry

• Follow-Ups:
  • RE: The limitations of XPath and navigation for XML databaseprocessing
    • From: "Michael Kay" <mike@s...>
  • Re: The limitations of XPath and navigation for XML databaseprocessing
    • From: Jonathan Robie <jonathan.robie@r...>

• References:
  • Re: The limitations of XPath and navigation for XML databaseprocessing
    • From: noah_mendelsohn@u...