- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 6 Jan 2000 22:42:08 -0500
- To: esedlar@us.oracle.com
- Cc: geoffrey.clemm@rational.com, w3c-dist-auth@w3.org, anovosel@us.oracle.com, dbeech@us.oracle.com, vkrishna@us.oracle.com, jjc@jclark.com
From: "Eric Sedlar" <esedlar@us.oracle.com> This is an interesting issue--how do specify some set of XML elements that you want out of a document not available to you. This is basically the XML equivalent of a SELECT list in SQL. Yes! (It is comforting to know that at least one other person out there worries about this kind of thing :-). In the versioning context, it comes up in the REPORT method. An important report is a DAV:available-reports report (analagous to an OPTIONS call, but returning the reports available, rather than the methods applicable). I raised this issue in the database context with the W3C people a few months ago, to raise the issue of a simplified form of XPath for this purpose. I proposed basically using a list of XPath identifiers, omitting elements in the predicate that reference the value of any node. I'm copying this to some relevant XML & XPath people to highlight WebDAV PROPFIND requests as another application for this usage in addition to database data retrieval. It's kind of disturbing to me to see invalid XML used for this--I'd prefer a comma separated list of XPath specifications, omitting predicates, like: <D:prop xmlns:R="http://www.foo.bar/boxschema/"> R:bigbox, R:author, D:supportedlock/lockentry/lockscope </D:prop> I think this will avoid confusion, since a list of XML element names shouldn't appear as empty elements. My concern with this approach is that the parser won't know that this identifier is an element name, so the application would have to do the processing itself (e.g. keeping track of the namespaces defined in that context, and replacing the namespace prefix with the appropriate URL). This is feasible, but does require the application to internally contain parsing knowledge. The alternative, using empty elements that violate the element definition avoids this problem, at the cost of being invalid XML. For the DAV:available-report REPORT, I have avoided the problem by defining DAV:xxx-report to be the element returned in the DAV:available-reports response, DAV:xxx-report-request be the element in the request body for that kind of report, and DAV:xxx-report-response be the element in the response body for that kind of report. But for the (recently added) DAV:property-report REPORT (which does a PROPFIND on the resources referenced by properties that are a list of href's), I can't avoid the "XML-select" problem. Cheers, Geoff
Received on Thursday, 6 January 2000 22:42:12 UTC