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

Re: The Goals of XML at 25, and the one thing that XML now needs

  • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • To: xml-dev <xml-dev@lists.xml.org>
  • Date: Wed, 21 Jul 2021 14:29:55 +1000

Re: The Goals of XML at 25
If I were to make up some scope goal for an evolution of XML I would say:

NON-GOALS

1. The language MUST NOT be lexically identical to or a subset of XML.  Nevertheless, as much of XML markup should be supported as possible, and gratuitous incompatibilites avoided.
   Rationale: been there, done that.
  Note:  Some XML, MiniXML and Canonicalized XML documents should be recognized/recognized. 

2. The language MUST NOT have an identical or subset infoset to the XML Infoset. Nevertheless, as much of XML infoset should be supported as possible, and gratuitous incompatibilities avoided.
   Rational: been there, done that.
   Note:  Some accepted XML, MiniXML and Canonicalized XML documents should have the same infoset. 

3. The language MUST NOT be characterizable by WebSGML (ISO SGML as extended, e.g. by Annex J and K) without the use of the SEEALSO capability.  Nevertheless, where WebSGML allows some approach it should be adopted as much as possible, and gratuitous incompatabilities avoided.   
   Rationale:  without SEEALSO requirements, it is treading water 
   Note: Some conforming SGML parsers should recognize/parse some documents in this format, at a lexical level. 

4. The language MUST NOT be, for every possible document, completely interconvertable with JSON. Nevertheless, where some graceful degration during inter-conversion which is better thanis possible between XML and JSON, is possible, it should be considered.
   Rationale: we already have JSON
   Note: Graceful degradation should still be possible.

5. The language MUST NOT support all declarative possibilities of XML Namespaces. It MUST be possible to know that a name has a namespace from its lexical form.  It MUST be possible to determine a namespace URL by scanning back far enough in the document to find the lexically most recent xmln:XX declaration for that value (i.e.a text operation, not a tree operation).
   Rationale:  horrid
   Note:  This means that no default namespace are allowed: if a name is in a namespace, it has a prefix. It also prevents nested redeclaration of prefixes: the most straightforward way to meet this is to ban any redeclaration of namespace prefixes. 

6. Language design choices MUST NOT be made which compromise the potential efficiency of parsing, especially in regard to data locality and parallel-parseability. 

GOALS

0. The language is a markup language. It should support mixed content.  It should support humans. 

1. The language should support non-modal parsing: at every point in a document, the parsing mode can be re-established by scanning forward without knowledge of prior context until a milestone is found.
    Rationale: this is necessary to support parallel parsing, and better editing
    Note:  I expect the milestones are < and >.  In other words, these characters must only ever be delimiters or part of delimiter strings. 

2. The language should support straightforward right-to-left parsing with the same ultimate result as left-to-right parsing.  
    Rational: this is necessary to support parallel parsing, and better editing.
     Note: This means that some tags can only be recognized at their last (leftmost) delimiter: for example, the in left-to-right parsing, a start-tag and end-tag are distinguishable at their opening delimiters but a start-tag and an empty-tag are distinguishable only at their closing delimiters; for right-to-left parsing, it is the start- and end-tags which are only distinguishable at the end of the string (i.e. the start tag)

3.  The language should support arbitrary streams of elements, where the document close is not signalled in the document but by the transport system.
    Rationale: Using tags to indicate data transport information may be considered a layering violation.  This may be useful for log files, financial information.
    Note: In SGML terms, we might say we have an implied top-level element. In XML terms we might say that we are providing XML entities not XML documents.

4.  The language must support some significant extra features to XML, to be decided.  It should attempt to do this by assigning meaning to existing lexical charactistics: these alternatives include that the empty-end tag versus a matched pair, or attribute values with no delimiter, or double quotes or apostrophe. One such feature to consider should be simple attribute-value lexical typing in undelimited comment values.  

And so on.  ..,  Keep adding compatible goals until it becomes compelling and hangs together as a thing in its own right.

Cheers
Rick


[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.