If I were to make up some scope goal for an evolution of XML I would say:
NON-GOALS
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.
You are assuming that interconversion means xml -> JSON -> xml, yes?
The basis of my suggestion is that JSON and XML both exist, and it is just wishful thinking and no value to merely re-duplicate them with different syntax. I simply don't care that JSON data cannot round-trip with XML (or is it XSD that has the issue?) neatly: not that it is not a valid concern for someone else: bandaids and low-hanging-fruit upgrades are good. But syntax is not that important, once there is one syntax that is good enough. Features (~infoset) are more important, as are focus, suitability, similarity-to-favourites, and community and ecosystem and hype.
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
Good reference. Yes, there are many ideas that fit the language family that could be considered.
For example, I would like to build xml:id into the language. That is direct syntax that allows datatyping, so it fits in. Is predefining xml:id a simplification? From the POV of local minimalism, no it should be a separate layer; but from the POV of language minimalism, yes because it removes an unnecessary layer (and optionality.)
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.
The non-model requirement entails, I think, that CDATA section must be removed. Also that numeric and entity references must be allowed and dereferenced in PIs and comments. (It does not necessarily mean that they must be allowed in element, attribute and PI names, but they might.)
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.
That has many great ideas, and I like that they add delimiters. It was a valuable excercise. But its premise, 100% round-tripping with JSON, is the opposite of mine.
And what does FtanML show, really? That when you do attempt a JSON with XML delimiters, you dont get a thing that looks like XML (or which existing XML systems could support with trivial tweaks) much anyway.
If an XML-environment person needed to have JSON features, would they choose FtanML or would they just choose JSON? And vice versa.
Regards
Rick
