Re: The limitations of XPath and navigation for XML databasepr
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format