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 22:28:46 +0000
To: public-qt-comments@w3.org
Message-Id: <E1OJwQY-0002sf-W8@jessica.w3.org>

--- Comment #3 from David Carlisle <davidc@nag.co.uk>  2010-06-02 22:28:45 ---
(In reply to comment #2)
> Reading the specification again, and thinking about how one might "soften" the
> wording, I'm inclined to recommend keeping it as it is.

I've some sympathy with this (that the behaviour be specified) although I could
probably make use of a more lenient parsing regime if it were allowed. One of
the main use cases for fn:parse that I'd see is parsing inline fragments of
markup (often CDATA quoted) if the markup is actually xml, as needed by the
"strict" interpretation of fn:parse() then arguably the function is just
helping with a poor design style anyway, the markup would have been better
unquoted and parsed as part of the original source, however a common case is to
have quoted html fragments (atom/rss feeds are often like this for example) and
there it's harder to say the source is using a bad style since it would not be
well formed if unquoted.

perhaps (as with serialisation) html should be seen as an important special
(and w3c defined) special case and a standard (perhaps optionally supported)
hook be provided, perhaps a 2 argument form where the 2nd argument is a Qname
naming a method (cf the methods specified in xsl:output) so
xml html or a system-defined name like saxon:gedcom. But maybe this is going
too far, since a standard function with an argument naming a system-defined
behaviour is really just an extension function in disguise. A standard way of
parsing inline html fragments would be nice though....

If the intention is to mandate xml input perhaps it should say it more
forcefully, since (as I said in the original comment) my initial assumption
(until I got to the error message description) was that since the details of
XDM construction were implementation defined, you _could_ push this to
accepting non xml, although reading it again, perhaps that was always a
slightly "optimistic" reading, given the paragraph starts with This function
takes as input an XML document represented as a string.

In any case from the formal procedural point of view I'm happy that the issue
has had WG discussion and am happy to leave it to the WGs to resolve
appropriately thus this bug may be closed (or kept open if the discussion is
ongoing) with no objection from me, as original submitter

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 22:28:51 UTC

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