W3C home > Mailing lists > Public > public-qt-comments@w3.org > March 2015

[Bug 28181] [f+o3.1] xml-to-json: "whose content is such that validation would succeed"

From: <bugzilla@jessica.w3.org>
Date: Tue, 10 Mar 2015 14:21:59 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-28181-523-VPLiJRis0z@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28181

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
A separate but closely related problem is the fallback option of this function.
The specification states that this function is called "When a node is
encountered that is not valid against the schema for the XML representation of
JSON". What exactly does this mean?

If we turn to schema definitions of validity, then if a <map> element contains
a <wrong> element that is not permitted by the schema, it is the <map> element
that is invalid, not the <wrong> element. But I think the intention here is
that the fallback function should be called with the <wrong> element as its
argument. Whatever else, this certainly demands a more precise explanation.

Also, a map with duplicate keys is invalid against the schema: is it intended
that the whole <map> element should be passed to the fallback function in this
case?

A serious problem with the design is streamability. We don't know whether an
element is valid until we reach its end tag, by which time it is too late if
the implementation is doing streamed processing.

We could attempt a more restricted definition: the function is called when an
element is encountered that is not permitted by the content model of its parent
element, or in the case of the top level, an element that has no declaration in
the schema.

Alternatively we could drop the option. It's not clear that it's really useful,
in comparison with transforming the XML first to something that conforms with
the schema. I would vote for dropping it if only because it's less work than
fixing it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 10 March 2015 14:22:02 UTC

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