[Bug 29009] fn:xml-to-json should not be restricted to xs:untyped

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29009

--- Comment #1 from Josh Spiegel <josh.spiegel@oracle.com> ---
A few more thoughts on this...

If you assume the restriction to xs:untyped instances is removed, the
requirement that validation "would succeed" becomes slightly inconsistent with
the mappings that are defined in terms of atomization and casting.  

For example, consider this query:

  let $input := validate type xs:float { <fn:boolean>0.0</fn:boolean> }
  return
    xml-to-json($input)

In this case, data(validate { $input }) would fail.  However $input cast as
xs:boolean would succeed.  

Assuming the restriction to xs:untyped is removed, I think the definition
should then be adjusted in one of the following ways:

Option 1: Abandon the requirement on $input that validation "would succeed" and
only describe what the function does.  In my opinion, this requirement is small
burden on the user and the implementor since both have to think about the
details of the schema and how validation would work.  The intent seems to be
that neither the user nor the implementor has to invoke the validator but
somehow ensure that it would be possible.  If the requirement is removed, I
think bullets 1-8 can remain mostly the same and it would just be a matter of
explicitly specifying some error conditions (e.g. what to do when an element
doesn't match a global element name, what to do when a cast fails, etc.)

  or

Option 2: Align bullets 1-8 more closely with validation.  For example, in
bullet (3) it says:

  "An element named boolean results in the output true or false depending on
the result of atomizing the element and casting the result to xs:boolean."
  This  would instead say something like:
  "An element named boolean results in the output true or false depending on
the result of validating the element and atomizing the result."

Note, the above example (which seems like a corner case) would be allowed under
Option 1 and would be an error under Option 2.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 3 August 2015 16:56:54 UTC