See also: IRC log
<scribe> scribe: TK
<scribe> scribeNick: taki
CB: We have published EXI for
JSON draft on Thursday.
... XML spec currently used is outdated.
DP: I noticed HTML looked
different.
... The one I generated was different.
CB: I directly fixed. Processed version was missing.
<dape> www.w3.org/2007/10/htmldiff?doc1=http://www.w3.org/TR/exi-for-json/&doc2=https://www.w3.org/XML/EXI/docs/json/exi-for-json.html
CB: If you update xmlspec, it
would be a better solution.
... I did not change XSL.
DP: xmlns in the example somehow uses "https".
<caribou> https://www.w3.org/2015/EXI/json
DP: Validator failed because it was expecting "http".
<dape> https://www.w3.org/TR/2016/WD-exi-for-json-20160128/schema-for-json.xsd
CB: We have inconsistency.
<caribou> xmlns:xs="https://www.w3.org/2001/XMLSchema"
<caribou> targetNamespace="https://www.w3.org/2015/EXI/json"
<scribe> ACTION: DP to modify XML Schema contained in appendix B to use "http" instead of "https". [recorded in http://www.w3.org/2016/02/02-exi-minutes.html#action01]
<trackbot> Created ACTION-734 - Modify xml schema contained in appendix b to use "http" instead of "https". [on Daniel Peintner - due 2016-02-09].
DB: target namespace is URL. it is ok to use "http".
DP: For processors the two are different, and it failed.
DB: "http" is directed to "https" when I typed in the browser.
CB: Server does that.
DB: If you use browser that
doesn't support https, it would use http.
... Dumb client would use http, then?
CB: Correct.
<brutzman> thank you for explaining that dumb clients will not get negotiated and not be redirected
DP: It is safer to use plain http.
<dape> TK: experimented with EXI for JSON
<dape> ... idea was to play with XML schema support
<dape> ... Don also found issue with JSON syntax. Thanks!
<dape> ... found difficulties to create XSD for EXI for JSON content
<dape> ... e.g., link is a map with two optional key/value pairs
<dape> ... XML structure uses "key" attribute for JSON key
<dape> ... EXI grammar generation has issue resolving that (see proto grammar)
<dape> ... propose to use different way to specificy name
<dape> ... proposal is that name becomes attribute name itself.. with empty string
<dape> .. <string key="manager">Boss</string> becomes <string manager="">Boss</string>
<dape> ... schema has ambiguity ... two times "string" element
<dape> DP: "old" cos-ambiguity issue with XSD?
<dape> TK: Correct. issue for XSD processors, .. however no issue for EXI grammar generation rules
<brutzman> Link to email on this topic: EXI for JSON structure, https://lists.w3.org/Archives/Public/public-exi/2016Feb/0000.html
DP: I didn't have time to look closely at this. I will take a look.
<brutzman> Request: for comparison, might someone post the expected conversion of that JSON snippet to EXI XML on the mail list?
DP: On the other hand, it will be a different approach from others are taking, such as XQuery and others.
DP showing the differences.....
DB: The new structure may cause some issues in making XPath query.
DP: We need to solve an issue of creating a dedicated schema.
<brutzman> A merit of the current schema is that all of the JSON keys and JSON key values can be directly referenced in XPath expressions. An XSLT program (or other XPath query) can iterate over all of the key="someUniqueFieldName" attributes.
DP: I also have an alternative idea, and will try if it would work or not.
<brutzman> A significant problem in the suggested alternative is that no key attribute can be directly accessed or iterated over. Each key attribute name has to be discovered before the corresponding value can be accessed. This greatly complicates document parsing.
<brutzman> Please explain "issue of creating a dedicated schema" ? The working-draft EXI for JSON schema would seem to be able represent any JSON document.
DP: Don, if you are aware of another way to help solving this issue, that would also help.
<brutzman> Restatement: am not sure what problem we are trying to fix. If we can represent any JSON structure in the provided XML encoding, then EXI can compress it, correct?
DP: EXI for JSON currently uses
generic schema. It currently does not provide a way to use
specific schemas.
... There is nothing wrong in the current spec.
<brutzman> If the motivation is to confirm the validity of a JSON object, then jslint and jshint can be used. If the motivation is to confirm the content-validity of a JSON structure, then a JSON Schema might be used.
DP: We did discuss in the past that we should provide a way to describe specific structure.
DB: jslint validates JSON syntax.
<brutzman> Yes, these two approaches are analagous to well-formed XML, and to schema-valid XML, respectively.
<brutzman> Further information about JSON Schema can be found at http://json-schema.org
<brutzman> Latest JSON Schema is RFC draft https://tools.ietf.org/html/draft-zyp-json-schema-04, expired 4 August 2013.
<brutzman> Incidentally, I haven't found information about whether JSON Schema work remains active or will resume... disappointing that status isn't clear on the website.
<brutzman> The motivation is clearer - thanks for the explanation. Not sure if I see a problem. If the goal is deeper validation, then "let JSON be JSON" and use JSON tools to validate a given structure.
DP: Generic schema is very
generic.
... Currently, we do not provide as good compaction as EXI does
for XML.
<brutzman> Curious side effect: since JSON Schemas are themselves written in JSON, those can also be expressed as EXI XML. That is sort of like second-order abstractions however, probably not very practical or useful.
DB: It is a merit to use generic schema for EXI for JSON.
DP: However, it does not know about specifics, for example "family" in this specific case.
<brutzman> The general nature of XML Schema for EXI JSON seems to be a significant merit. It is able to express any arbitrary JSON structure, and then take advantage of a primary strength of EXI: type-aware data compression.
<brutzman> Conceivably the motivators we are discussing are building the case for establishing a more comprehensive mapping between JSON structures and content-specific XML Schemas.
<brutzman> Some months ago we discussed possible general mapping of structured JSON content to a correspondingly structured XML Schema.
DP: I think we need to be careful because the old way allowed more compact implementation because it only needs to be aware of "key" attribute.
<brutzman> We have had to work through a number of issues in the X3D Encoding for JSON. http://www.web3d.org/x3d/stylesheets/X3dToJson.html
<brutzman> There are some fundamental gaps in data models: a strict object-oriented JSON approach is different than a more flexible XML document approach, even when PSVI limits are accepted.
<brutzman> I think we made the right choice with EXI for JSON, your approach looks great. Let's keep testing... a more general approach is conceivable but it is definitely future work and would need much more effort.
<brutzman> In the case of X3D JSON, we found a number of data-modeling issues where well-defined and valid .x3d XML documents were not directly expressible as JSON. Thus we made some adaptations and tradeoffs, 100% round-trip conversions remained out of reach.
<brutzman> We have probably gotten to ~95% bidirectional mappings between the XML data model and the JSON object model. Other XML schemas may have further issues that we didn't have to address.
<brutzman> http://www.web3d.org/x3d/stylesheets/X3dToJson.html#Issues
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/plain/plain http/ Succeeded: s/These/Yes, these/ Succeeded: s/not/for/ Found Scribe: TK Found ScribeNick: taki WARNING: No "Present: ... " found! Possibly Present: CB DB DP Request Restatement TK brutzman caribou dape exi https joined scribeNick trackbot xmlns You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 02 Feb 2016 Guessing minutes URL: http://www.w3.org/2016/02/02-exi-minutes.html People with action items: dp WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]