[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] The limitations of XPath and navigation for XML databaseprocessing
- From: "W. E. Perry" <wperry@fiduciary.com>
- To: xml-dev@lists.xml.org
- Date: Fri, 08 Feb 2008 15:35:53 -0500
Jonathan Robie wrote:
> How are you using the term "semantic" here?
Hi Jonathan.
I am using the term "semantic" here exactly as I have during the nearly ten years that you and I have been discussing this: semantics (semantic data artifacts, data
items in which semantic properties inhere . . .) are properties elaborated by a process run against a text (in the case at hand, XML/XPath syntax) on a particular
occasion, in a particular environment. The semantics or semantic properties thus elaborated are fully and severally conditional upon the instance version of the text
thus processed; upon the particular process; and upon each of those salient features of the occasion or of the environment which can be shown to have contributed to or
conditioned the instance semantics elaborated. Semantics thus elaborated are not imparted to the instance text which was an input to the process, any more than those
semantics are imparted to the occasion or to the environment on which that process was run. Rather, as a result of that instance operation of the process, semantics
(again, semantic data artifacts, data items in which semantic properties inhere . . .) are elaborated as an outcome and have instance existence (avoiding the Platonic
Forms trap . . .). You've heard all of this before.
> To me, table names and column names are labels in the same way the elements and attributes are labels.
In Michael David's argument, table names and column names are perceived as semantically endowed--as data items in which semantic properties inhere--as opposed to the
A/B/C of Noah's example, which fall somehow short of that semantic endowment because they are 'merely' syntactic artifacts. It seems to me that what is troubling
Michael David about the XML/XPath artifacts is that they clearly require some further processing--which they do--before the semantic properties perceived to inhere in
the name of a Department or in the identity of an Employee are elaborated from the syntactic artifacts 'DeptID' or 'Empno'. In Michael David's view, it appears, the
Empno manipulated by SQL is manipulated as a semantic artifact because he feels that SQL truly addresses the semantic identity of an employee while XPath is mired in
the syntax of 'Empno'--a syntax which would require processing before it might be manipulated a a semantic artifact. Michael David is not alone in thinking this way. We
had the same discussion here with much heat when John Cowan first promulgated the Infoset.
> XQuery is actually defined in terms of a data model, not character text. That's why you can't address just a start tag or an end tag, for instance, or create XML that
> is not well-formed.
Defined, in fact, in Infoset terms, which still look the same to me as they did eight years ago: http://lists.xml.org/archives/xml-dev/200007/msg00945.html That said,
I like XQuery *very* much--even as I am still unsteadily learning it--and in significant part because it honestly separates its premises from those of XPath in just
this way.
Respectfully,
Walter Perry
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]