W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2011

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 30 Nov 2011 15:04:41 +0000
To: public-qt-comments@w3.org
Message-Id: <E1RVliD-0000xp-EA@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14932

Jonathan Robie <jonathan.robie@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonathan.robie@gmail.com

--- Comment #6 from Jonathan Robie <jonathan.robie@gmail.com> 2011-11-30 15:04:39 UTC ---
(In reply to comment #5)
> in an ideal world, there should be resolve-uri(),
> then interaction (maybe specifically supported for HTTP), and then handling the
> result, so that users could resolve() a relative URI, GET() an XML resource,
> and then parse() it into an XDM. i think not separating these issues cleanly
> has created the situation reported in this bug, and 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.

However, doc() does not necessarily involve GET() and parse(). Any solution
needs to work well for:

* Retrieving Web resources
* Persistent XDM instances in native stores
* Identifying data in foreign systems like relational databases
* Local files
* Data converters

I'm probably missing some important use cases - implementations do wildly
different things with doc().

Web friendliness is important. Let's make sure we don't achieve that at the
expense of data integration.

-- 
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 15:04:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:37 UTC