Re: [xml-dev] XMON

[Rick Jelliffe <rjelliffe@allette.com.au>]

Oh, yes I certainly read both of them. I try to read every paper you give. 

I guess the difference is that my XML parts are XML and my JSON parts are JSON. To me, the XSLT JSON/XML exchange reeks of the same problem that XSD had: it tried to solve a syntax problem by larding on concepts and markup. Which is not to predict failure, at all. 

That is why I think an extended DOM/XDM is necessary, the ideal approach for XSLT  for  this kind of thing is for XPath to add a special axis for accessing unnamed 'elements' (if it is JSON as content in XML,) or unnamed 'attibutes' (for XMON syntax.)

The proper treatment of JSON isn't to convert it to elements. It is to convert it to structs (are arrays and maps...fine) but then to be able to step through them with XPath, surely. Abbreviated syntax is the glory of XSLT. (Apologize yet again if XPath does indeed have an axis and node types to drill from an element into a JSON expression: I mean a node type and abbreviation not a function.  For example, 

  /top//container/#[1]//taxnumber   

Where # means an embedded JSON struct and the second // is operating in JSON only.

Regard

Rick

On 4 May 2017 19:23, "Michael Kay" <mike@saxonica.com> wrote:

It would probably be a good idea to re-read the FtanML proposal at

https://www.balisage.net/Proceedings/vol10/html/Kay01/BalisageVol10-Kay01.html

I don't think it got everything right, but I think it contains some good ideas along these lines.

At the level of tree models I have come to realise that there is a fundamental difference between XML tree models and JSON tree models that has nothing to do with the differences in syntax: XML trees have parent pointers, JSON trees don't. As I tried to show in my XML Prague paper last year, this has surprisingly far-reaching effects on the design of a transformation language.

http://archive.xmlprague.cz/2016/files/xmlprague-2016-proceedings.pdf

Michael Kay

Saxonica

On 4 May 2017, at 07:37, Rick Jelliffe <rjelliffe@allette.com.au> wrote:

XML was ascendant for 10 years and overhyped. The second 10 years of its life its has been descending to be merely used where it is appropriate, which is the best any technology should hope for. Classic hype cycle, I guess.

But in order to thrive, I think it needs to grow and morph into something more. What is the low hanging fruit, that would give a great increase in functionality with the maximum ability to connect to existing technology by small shims? 

I would suggest it is to embrace JSON as doing a different but compatible thing to elements and content (apologies if I am just repeating someone else's suggestion):  lets prune and embrace!

<?xmon?>

<!-- Example -->

<some-element  xml:id="me"  class="plenty'

   {
       "name":"Rick", "age":856, "city":"Sydney"
   }

>Hello &#x2022;<b>World</b></some-element>

<?checksum 0x12356775756?>

I.e., UTF-8, DTD-less, namespace-less XML allowing some well-defined version of JSON in start-tags after attributes.  Prefixes useable for open standard vocabularies.

Not WF XML or JSON, but trivially convertable to XML by putting the JSON into an first element <json>  or to JSON by pulling in each fragment, or whatever.  But the intent would be to use an extended DOM with JSON nodes. 

It allows JSON to be used with mixed content and schemas. The XML parts can be accessed with XPath as usual, and so Schematron, RELAX NG, XSD etc come along for the ride.   I expect XSD would be overkill, in that you we can use syntax to express the type rather than needing some kind of post-schema-validation-infoset.

Regards

Rick Jelliffe