W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2010

[Bug 9751] [FO11] fn:parse on non-xml input

From: <bugzilla@jessica.w3.org>
Date: Wed, 02 Jun 2010 21:59:44 +0000
To: public-qt-comments@w3.org
Message-Id: <E1OJvyS-0001Te-3x@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9751





--- Comment #2 from Michael Kay <mike@saxonica.com>  2010-06-02 21:59:43 ---
Reading the specification again, and thinking about how one might "soften" the
wording, I'm inclined to recommend keeping it as it is, despite what was said
at the telcon. If the user wants a function that does something different from
this, for example a function that parses HTML, then I think that should be a
different function. Otherwise we seem to end up with a function that takes a
string as input and produces a document node as output, using a process that is
completely implementation-dependent with no guarantee of interoperability.

I think this case is different from doc() where the function accesses an
external resource. In this case the input and output are entirely within the
domain of the XSLT/XQuery processor, and I see no reason to make the behaviour
implementation-defined except to the limited extent that XML parsing is
intrinsically implementation defined.

Of course, if products are designed to allow users a choice of XML parser, then
it might be possible for users to subvert the behaviour of this function to do
something different from what it says in the specification. But I don't think
that's something that the spec should encourage or endorse.

-- 
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, 2 June 2010 21:59:48 UTC

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