[Bug 14932] [FO30] fn:unparsed-text


--- 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