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
