- From: <bugzilla@jessica.w3.org>
- Date: Wed, 30 Nov 2011 16:17:24 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14932 --- Comment #7 from Erik Wilde <erik.wilde@emc.com> 2011-11-30 16:17:23 UTC --- (In reply to comment #6) > > the cleanest solution would > > be to separate the steps, expose them as functions, and then just define doc() > > as a combination of the basic function. maybe that's too ambitious, but > > personally, i'd like to see XQuery's web-friendliness increased anyway. > I think it's useful to have functions that do each of these things. is there any way this could become part of a more long-term plan to improve XQuery/XSLT functionality in that area? > However, doc() does not necessarily involve GET() and parse(). sure, it all depends on the URI scheme. but maybe it should be possible to (a) find out which URI schemes are supported by an implementation, and then act accordingly, such as dereferencing the URI. HTTP and file probably would be two schemes that would be supported by most implementations. > Any solution needs to work well for: > * Retrieving Web resources and that could also mean using protocol-oriented schemes such as FTP, if supported by the implementation. > * Persistent XDM instances in native stores how are these identified right now? nothing prevents an implementation from not actually performing an HTTP request if the resource is available locally, but logically, this still is access based on HTTP URIs, right? > * Identifying data in foreign systems like relational databases how is this achieved right now? nothing that is just URI-based, i assume? > * Local files there's the file URI scheme for that. > * Data converters how is this achieved right now? nothing that is just URI-based, i assume? > I'm probably missing some important use cases - implementations do wildly > different things with doc(). do they do any magic that is not in line with web architecture? if not, then separating the currently mixed concerns might help. > Web friendliness is important. Let's make sure we don't achieve that at the > expense of data integration. i don't see how a more orthogonal design of web-oriented functionality would create problems for data integration. on the contrary, data integration often will be based on being able to take full advantage of web architecture, and if i don't have control over, for example, HTTP methods and headers, then there are a lot of things i just cannot do with data that is exposed on the web. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 30 November 2011 16:17:47 UTC