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.
Okay, so NewML has to be a superset of a subset of XML, more or less.
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.
Alas, I am not an SGML maven, so I can't interpret that without much research.
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.
That's not practical, unless you are talking about shallow conversions only. Every SGML property set is a hierarchical object whose leaves are strings, and as such is representable in JSON -- which means in practice that every data format is representable in JSON.
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).
See <
https://www.w3.org/TR/1998/NOTE-xml-names-0119>, which uses PIs right after the XML declaration of the form <?xml:namespace name='
http://www.microsoft.com/' as='ms' ?> No redefinition, no lexical scope. The W3C shot that down because they didn't want to exclude the possibility of XML documents being streamed out by nested calls to functions that want to use namespaces their callers know nothing about. But is that realistic? Most of the XML I look at today declares a whole mess of namespaces on the root element, even if they aren't all used.
You might want to print it as a PDF or use Just Read (or a similar browser plugin) to shut off the maddening stylesheet and its Big Read Warning Box.
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.
Note that explicit ">" is banned by MicroXML except when it's a delimiter (this is already true of "<"). CDATA sections or anything like them can't work like this, unless you write <!CDATA[blah blah blah]CDATA!> or something of the sort.
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.
