- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Jun 2010 22:28:46 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9751 --- 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