This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27489 - [XSLT30] XHTML representation of JSON
Summary: [XSLT30] XHTML representation of JSON
Status: CLOSED WORKSFORME
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-03 01:54 UTC by Brett Zamir
Modified: 2015-10-29 09:50 UTC (History)
1 user (show)

See Also:


Attachments

Description Brett Zamir 2014-12-03 01:54:10 UTC
Looks like I may be too late for this, but I wanted to recommend consideration of using an XHTML representation of JSON which would have the advantages of:

1. Being able to be created in a WYSIWYG fashion and supplied in environments which only allowed X/HTML.
2. Being human readable without transformations

I started such a format at http://brettz9.github.io/jhtml/ (though I indicated some changes I might like to make to the "spec": https://github.com/brettz9/jhtml#user-content-possible-future-spec-modifications )
Comment 1 Michael Kay 2014-12-03 07:54:48 UTC
I don't see a spec anywhere, only a simple example. Are we expected to infer the spec?
Comment 2 Brett Zamir 2014-12-03 08:05:45 UTC
It's not well or formally written, but I have some rules documented at https://github.com/brettz9/jhtml#user-content-rules with some possible desired changes at https://github.com/brettz9/jhtml#user-content-possible-future-spec-modifications . But the demo source should be pretty self-explanatory too though, I think. But again, I know not very formal...
Comment 3 Brett Zamir 2014-12-03 16:02:40 UTC
And my apologies... I should clarify that the following unfinished branch reflects my most recently intended syntax: https://github.com/brettz9/jhtml/tree/unfinished-new-spec

The README of this branch (and its index.html demo file) follow even simpler rules (though the JavaScript library has not been updated to transform the new structure).

Besides simplification and avoidance of hidden properties (by avoiding most of the hidden Microdata properties I had formerly employed), the reason for the new rules is that in now requiring the <i> tag on null, boolean, and numbers, they can always be visually distinguished from strings even when no CSS is applied.

As far as other design choices, my hope was to make as little markup required as possible to allow for hand-coding. 

Finally, although HTML's "Microdata" (as I required to be present at the root of these JSON-as-XHTML structures) is not intended for denoting hierarchical relationships, its itemtype attribute it is the closest thing to namespaces in plain HTML, and it also should allow for XML/XHTML environments to uniquely distinguish such encodings from regular XHTML (since using the XHTML namespace would still be desirable for rendering the documents in XHTML environments).

Also, as Microdata attributes are purely to be used for semantic purposes, it can be safe for HTML editors and such to whitelist.
Comment 4 Michael Kay 2014-12-18 21:32:00 UTC
The WG considered this suggestion today.

We felt that there might well be cases where a mapping of JSON to XHTML of the kind described here might be useful, but that such a mapping could be achieved by taking the output of the json-to-xml function and transforming it using template rules. The mapping defined in the specification was never intended to meet everyone's final needs, merely to be a lossless representation of the JSON content that could readily be transformed into whatever form the application finds convenient.

Many thanks for bringing this idea to our attention. We are closing the bug report with no action.