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

[Bug 27498] [ser 3.1]Unfailing serialization

From: <bugzilla@jessica.w3.org>
Date: Wed, 21 Jan 2015 22:54:16 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-27498-523-Fz7vsykjGE@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27498

--- Comment #14 from Andrew Coleman <andrew_coleman@uk.ibm.com> ---
I think you make a good point (comment 13), and I agree that we could make a
better effort to handle the examples you have given.  However, the wording that
you have proposed does not directly align with any of the rules in the JSON
output method.  We could ammend the first and second rules (starting with 'An
array item...' and 'A map item...') to say that all members/values are
serialized using the adaptive method as you have suggested, but the adaptive
method would loose the ability to output chunks of JSON syntax for portions of
the XDM that contain valid JSON data.

The primary design principle for the adaptive method was to be able to take XDM
instances that contain a mixture of data from XML and JSON sources and output a
serialized form that contains a mixture of XML syntax and JSON syntax.  And at
the same time, try and avoid throwing errors when other noise gets into the
mix.

I think would could avoid throwing the errors you have observed by amending the
'catchall' rule in the JSON output method to say

* Any item in the data model instance of type not specified in the above list
will be serialized using the Adaptive output method, rather than raising a
serialization error [err:SERE0021].

This amendment would be in addition to all the other amendments currently in
the working draft.

This would allow single functions in maps and arrays to be serialized without
throwing an error.  

We would need to convince ourselves that there aren't situations where we go
into infinite recursion.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 21 January 2015 22:54:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 January 2015 22:54:18 UTC