- From: <bugzilla@jessica.w3.org>
- Date: Mon, 05 Jan 2015 18:56:09 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27498 --- Comment #7 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> --- If we adopt round-trippability as a requirement (as implicitly suggested at least for arrays and maps in comment 5 and endorsed in comment 6), does the requirement also apply to XML data? One story that would be simple to tell would be: serialize it using a new serialization method, and then you will be able to reconstitute an isomorphic collection of XDM data from the serialization. We seem to be missing a couple of things here: 1 a way to annotate XML nodes with type information that can be reliably reconstituted (as long as all the appropriate in-scope schema information is available) -- remember that revalidating with the in-scope schema starting at the root of each maximal XDM tree is not guaranteed to produce the same results; 2 a way to read the serialized data and re-type everything the same way. It's not clear at first glance how best to add the type annotations required for reliable write + read round tripping for either JSON or XML, without getting in the way of non-XDM systems. And it would be nice to be able to serialize the entire collection of data without loss; but that involves being able to handle parentless attributes and functions (and possibly other things I'm forgetting at the moment). Or is there a plausible subset of XDM for which reliable write + read round-tripping can be easily defined and which will suffice for all imaginable purposes? all rational imaginable purposes? all rational purposes that don't involve meta-programming or other unusual or unnatural acts? most rational purposes? many purposes? I thank Hans-Jürgen Rennau for pointing to some earlier discussions that have not been raised as bugs or enhancement requests in Bugzilla; I'll have to refresh my memory to see if solutions have already been suggested for these problems. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 5 January 2015 18:56:15 UTC