OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XMON

I guess another angle might be it would allow a more definite answer to 'what is the difference between an element and an attribute' which some people find anxiety-inducing.

You could say

 * If the information is mixed content or text aimed at humans, use elements.

* If the information is program data then use structs

* If the information is about identification, linking, navigation or formatting of elements, use attributes

* If the data is ad hoc notes for human operators then use comments

* If the data is ad hoc instructions for processing then use PIs (In which case, a PI should also be extended to allow structs)

So this actually increases the XML/SGMLyness of things, because we are interested in making explicit this separation of concerns in the syntax.  I am assuming here that just as SGML 'learned' the structure/comment/pragma split from programming languages and added attributes, and then programming languages 'learned' attributes from XML (and some are picking up named scopes a la elements, too), that XML can fruitfully 'learn' new something new from the web.

JSON successfully challenges one of the fundamental motivations of SGML: that the only practical way to send data between unknown disparate systems is to abstract out difference (and add them in individually and spevigically as needed.) I mean for storage type abstractions only (not to trigger Walter Perry's excellent points.)

Before JSON, this was a pragmatic assumption, after JSON it is silly. But JASON was not the cause but the solution that stepped in: we no longer have computer systems with 7 or 9 bit bytes as we had in the 70s, we don't have record-oriented text we use long strings, our floating points are more standardized, our character repertoire and transfer encodings are standardized with Unicode and UTF-8, programming languages are standardized and often support  the same core now due to FFI. What was impossible in the 70s  and 80s, and dodgy in the 90s is now status quo. 

So if one of the main underlying rationales for SGML/XML is now irrelevant, does that mean that XML itself is irrelevant? I don't need to Xplain why not on this forum ( Xplaining is the XML equivalent of mansplaining) :-)

XML now has a capability gap, and the most direct way to add is to extend XML to allow JSON syntax. Not as content, where you then need some extra-syntactic layer to say 'this is JSON here', but inside tags.


On 5 May 2017 22:55, "Alain Couthures" <alain.couthures@agencexml.com> wrote:
Le 04/05/17 à 16:20, Rick Jelliffe a écrit :
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.)

I have been thinking about an extended DOM/XDM for years (https://www.balisage.net/Proceedings/vol10/html/Couthures01/BalisageVol10-Couthures01.html and http://www.agencexml.com/amsterdam2015/Processing_non-XML_sources_as_XML.pdf) and my own _javascript_ implementation, for browsers and nodeJS, is now at alpha level with XPath/XQuery support. Because I chose to have my own DOM3 implementation, it was very easy, "for fun", to run xqib.org examples with it.

Working at DOM level, of course, allows to add node types, axes,... and specific parsers for non-XML data. Having its own XPath engine allows to add operators and so on (I have chosen full asynchronous evaluation because of functions like fn:doc(), http:send-request(),...).

I am happy with it for my own purposes and it's free opensource but I know that, nowadays, nobody is effectively interested in it but me...

Best regards,

Alain Couthures

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS