- From: Sarah Wilkin <swilkin@apple.com>
- Date: Tue, 11 Nov 2003 15:50:03 -0800
- To: Jonathan Robie <jonathan.robie@datadirect.com>, Michael Rys <mrys@microsoft.com>
- Cc: public-qt-comments@w3.org
On Nov 11, 2003, at 2:25 PM, Jonathan Robie wrote: > I don't really see a problem with the approach XQuery uses here. > Suppose I write a document that looks like this: > > <?xml version="1.0" encoding="utf-8"?> > <eg><![CDATA[<?xml version="1.0" encoding="utf-8"?>]]></eg> > > Now you do a query on the eg element, and get the following result: > > <eg><?xml version="1.0" encoding="utf-8"?></eg> > > Any XML parser understands what that means, and any experienced XML > user should know that the two are equivalent. Why is this problematic? You've already convinced me that this issue will not be resolved in the spec, which is why I wondered about standardizing supplemental features. The example you show is problematic because a user cannot create, with XQuery, a serialized representation of the XML to fit a specific format that a legacy application may expect. As much as we wish to ignore it, XML is scraped, manipulated with regular expressions, and string-matched all over the place. If a user wants to create a document that say, has all of its code sections wrapped in CDATA (instead of an element, to take use your previous example) so that an old perl program can scrape it out, it would be nice if he could use XQuery. On Nov 11, 2003, at 2:43 PM, Kay, Michael wrote: > these grumbles by adding features which would require fundamental > changes to the data model, and I can't see any intrinsic reason why > the situation with XQuery should be any different. I never suggested that the data model change, just that a computed constructor could be used to supply the same hints to an implementor as a static constructor. At any rate, I'll consider the issue closed. Thanks, --Sarah
Received on Tuesday, 11 November 2003 18:50:03 UTC