[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XMON

  • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • To: xml-dev@lists.xml.org
  • Date: Sun, 7 May 2017 14:26:43 +1000

Re:  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.

Regards
Rick

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

  • Follow-Ups:
    • Re: XMON
      • From: John Cowan <johnwcowan@gmail.com>
  • References:
    • XMON
      • From: Rick Jelliffe <rjelliffe@allette.com.au>
    • Re: XMON
      • From: Michael Kay <mike@saxonica.com>
    • Re: XMON
      • From: Rick Jelliffe <rjelliffe@allette.com.au>
    • Re: XMON
      • From: Alain Couthures <alain.couthures@agencexml.com>

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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.