James Clark's Random Thoughts

It seems to me, looking at JSON, that some program...

2011-10-24T20:57:28.488+07:00

It seems to me, looking at JSON, that some programmer who likes terse languages looked at XML and said "this is far to easy to read, let's get something that looks more archaic" - and invented JSON.

There seems to be this idea that "verbose is bad" - the same type of developer who rejects an easy to read language like visual basic in favout of something where you have to carefully scrutinise every line, like C#.

While JSON may be gaining traction, I believe that...

2011-06-27T23:17:07.745+07:00

While JSON may be gaining traction, I believe that XML and JSON serve different purposes by design. JSON is a data structure containment based system. XML is an extension based data representation scheme. In large part I agree that JSON is not well suited for some tasks, however, when it comes to programming : JSON contains simple rules compared to the complexities of tag attributes and mixed content. XML uses these attributes but does not enforce them nor give good reason to use them compared to wrapping things in tags from the many times I have used them. Consistently checking if I am in a mixed content node (lord knows if someone inserts a tag where there shouldn't be one) or an attribute node exists (did it get defaulted by a namespace?) instead of a consistent means of accessing data being used as such is confusing when deadlines are important. Schemas are amazing, and I wish it were easier to have them supported, but largely vendors will not give correct formed XML at all times, with JSON the risk is largely reduced due to lower complexity. Having mixed content and attributes is a strength for development of content in XML, but I largely feel that this added complexity to the programming side is hard to deal with compared to the simple set/map/value structures that are presented in JSON.

James, how would MicroXML fit in with Efficient XM...

2011-03-20T22:12:28.037+07:00

James, how would MicroXML fit in with Efficient XML Interchange (EXI)?

"In particular, JSON shines as a programming ...

2011-03-16T06:58:53.739+07:00

"In particular, JSON shines as a programming language-independent representation of typical programming language data structures."

What about references? Isn't this a typical programming language data structure that is missing in JSON?

I've taken a look at the current JSON schema p...

2011-03-11T05:18:56.364+07:00

I've taken a look at the current JSON schema proposals, and it appears to me that they miss the mark. Specifically, it appears to me that they don't allow context-free-grammar specifications as Relax NG does. Perhaps I'm being na\"ive, but it appears to me that there's a golden opportunity to just strip down the Relax NG syntax to match JSON: get rid of element tags and attributes, formulate a simple syntax for name->value mappings.

The result would appear to be a usable and efficient schema language for JSON.

No?

You should mention Tim Bray's XML-SW from 2002. Back then some people agreed but nobody cared, why should it be different today. Either you try to live with XML as great and broken as it is, or you choose some other language. Before XML it was ASN.1 and SGML, yesterday it was XML, today it is JSON and RDF, and the day after tomorrow something else. Every new language promises a revolution, but sooner or later it always evolves into a complex monster and other languages are proposed. This is just evolution.

I've put together a very preliminary MicroXML draft specification.

I have released MicroLark 0.8, a parser/writer/tree-model package for MicroXML written in Java. It implements MicroXML as specified in this post, with the addition of prefixed attribute elements (it allows, but does not require, declarations of those prefixes).

My previous concern that prefixes require declarat...

2011-01-14T23:37:56.655+07:00

My previous concern that prefixes require declarations ("xmlns:foo") is answered I now see by the above MicroXML limit to just the special (according to the XML Namespaces spec) prefix "xml:" which the said spec says doesn't need a declaration. Maybe we need a list of all the possible xml: values and uses (or a subset of them?) and requirements for implementing them (like not rejected them when mixed with another vocabulary/model).

John, David, Yes but wasn't the beauty of allo...

2011-01-14T16:06:00.097+07:00

John, David,
Yes but wasn't the beauty of allowing the xmlns="foo" namespace attribute that it preserved compatibility with XML Namespaces. Allowing prefixes in attributes, worthy though it's purpose may be, seems to me to be very costly if it breaks compatibility.

Steve, who saids you need to declare namespaces?! ...

2011-01-14T03:12:30.784+07:00

Steve, who saids you need to declare namespaces?! If something has a ns: prefix to its name - then assume it is processing instructions or other semantics, separate from the data content, otherwise ignore. Simple.

QName introduces the logic that the prefix part...

2011-01-14T02:12:21.179+07:00
QName introduces the logic that the prefix part MUST match a prefix in a namespace declaration, doesn't it?

Yes for XML with Namespaces, no for plain XML, and whatever we like for MicroXML. My proposal is to allow "foo:" in attribute names, but not to require "xmlns:foo" attributes to match them. If such an attribute is present, great; your document is XML with Namespaces compatible. In any case, attribute names are still just strings in the data model, whether they contain ":" or not.

The problem, I think, with namespaces for attribut...

2011-01-13T22:26:38.136+07:00
The problem, I think, with namespaces for attributes involving prefixes is that this introduces the concept of QName and I thought one requirement for MicroXML is that it allows the XML to be treated very much like just text. A QName introduces the logic that the prefix part MUST match a prefix in a namespace declaration, doesn't it? That seems to be too much for something intended to be so simple.

Steve, ignoring foreign namespace attributes works...

2011-01-12T03:50:10.801+07:00
Steve, ignoring foreign namespace attributes works great! Typically injection of attributes is a great way to pass processing instructions and directives that are not part of the data content. We use this in CAM for example to inject error, warning and informational parsing results. So we'd expect any handler to simply strip these out after digesting and acting on them.

Thinking about John's last comment, it seem to...

2011-01-10T18:25:19.038+07:00
Thinking about John's last comment, it seem to me that what makes namespaces useful to attributes is the potential use of foreign attributes. Attributes defined as part of a vocabulary do not need any additional namespace so they do not need a prefix (just a convention). Where something like 1 benefits from namespaces is when the attributes and maybe attribute values are from a foreign namespace, of course. Maybe would welcome, I think, a convention which says that such attributes need not be explicitly allowed by the vocabulary/namespace of the elements to be allowed in a MicroXML instance; the convention might be that they can just be ignored if their foreign namespace is not recognised in relation to the instance's namespace: But is that safe?

I found an interesting IBM DeveloperWorks article ...

2011-01-08T14:08:49.867+07:00
I found an interesting IBM DeveloperWorks article by Parand Darugar called "Abolish XML namespaces?" Most anti-namespace screeds are just whinges, but this one isn't.

I've linked to the section about the two use cases where he considers namespaces actually worthwhile. The first is in identifying a document type, which is what MicroXML @xmlns is for (although it can be used at the top of a subtree as well). The second is namespaced attribute names, and I'll quote it selectively here:

Namespaces have a compelling use in providing unique identifiers for type information. You may have seen XML fragments such as: [...]

<cost xsi:type="xsd:float">29.95</cost>

This conveys that cost has a type, and by type I mean type as defined by XSI, and that the type is float as defined by XSD. The key point here is that you are indeed looking for unique, non-context-related identifiers for each type. You are not combining your document with the XSD or the SOAP encoding document; you are simply referring to particular elements within each specification from your document. The specification need not even be in XML — you are referring to a flat structure, simply a list of types. If you believed that the type structure was hierarchical, you would need to fully qualify the path for the type, with something like:

<cost xsi:type="xsd:/types/simple/float">29.95</cost>

[...]

Perhaps this still isn't a reasonable use case for XML namespaces, but you have glimpsed a certain amount of usefulness. The lesson can be generalized as follows: A method for associating the attributes of elements with external reference points might have value [italics in original]. The element itself does not need a namespace, but its attributes might.

On reflection, I think MicroXML should allow prefi...

2011-01-02T09:57:55.010+07:00
On reflection, I think MicroXML should allow prefixed attributes. It's cleaner to have "json:type" than "json-type" in an attribute architecture, because you can have a "xmlns:json" attribute in the MicroXML to carry namespace information for XML processors without special hackery. MicroXML processors just see both "json:type" and "xmlns:json" as ordinary attributes with no magic properties, the same as "xmlns", and leave it up to the application to process them specially if at all.

Stephen (not D. Green): The obvious answer to the ...

2011-01-02T09:53:14.154+07:00
Stephen (not D. Green): The obvious answer to the attribute-type issue seems to me to be: Don't put data that needs to be JSON-visible into MicroXML attributes, or if you do, make sure it's string data only.

I've just posted my current thoughts on MicroXML and JSON.

I cannot agree with the first paragraph. XML is in...

2010-12-31T03:38:06.618+07:00
I cannot agree with the first paragraph. XML is indeed a good, simple, extensible format for documents. It has the enormous advantage of having large amounts of software tool infrastructure already in place. It's not perfect for all possible uses, but nothing is.

Kurt, MicroXML currently appears to be designed for people who want to build new parsers and software infrastructure, not for people who are creating, sharing, and reading documents. See for instance the difference in perspectives in the discussion of processing instructions in these comments. I agree that this does not seem like a compelling design rationale.

In the MusicXML world, for instance, UTF-16 encoding and processing instructions are absolutely necessary features. Who cares if these features may complicate life a little bit for parser implementers? The number of parser implementers is totally dwarfed by the number of people reading, writing, and sharing XML documents.

Stephen, now you're talking! Yes - with CAM te...

2010-12-30T23:46:27.527+07:00
Stephen, now you're talking! Yes - with CAM templates - we're using xslt to write XSD for developers. This is a key feature for NIEM. The raw XSD for NIEM cause most developer tooling to crash - too much recursion - too much complexity. By writing the equivalent from CAM templates in simple XSD syntax - it avoids those issues - and logically the CAM and XSD are equivalent.

So back to where you are at - generating XSD schema for MicroXML from a CAM template using xslt can work nicely - and results in dramatic simpler tasking for developers - because they do not have to be XSD syntax experts.

Sine CAM is essentially WYSIWYG XML structurally - the MicroXML instance can plug straight in there - and the XSD be generated automatically. Even seems like cheating at times!

For those who tend to use XSD (W3C XML Schema) wit...

2010-12-30T23:25:42.088+07:00
For those who tend to use XSD (W3C XML Schema) with XML and would like to use a very simplified version with MicroXML too, I've produced a cut-down MicroXSD 'schema of schemas'. It constrains XSD schemas for MicroXML to just 'local' elements and attributes (to avoid having to include more than one namespace and to avoid namespace prefixes). Within those constraints, the semantics would be the same as standard XSD. I've used the schema of schemas to generate random MicroXSD schemas using my favorite XML editor and subsequently used these random schemas to generate MicroXML-esque instances without any problems. It all makes MicroXML and a MicroXML stack including profiles for schema validation look quite feasible. 'Local' element and attribute definitions in an XSD schema have the advantage of making the schema look similar to the instances they constrain, I think (a bit like CAM and Examplotron).

Stephen, lets not tie ourselves to XML Schema and ...

2010-12-30T23:23:35.387+07:00
Stephen, lets not tie ourselves to XML Schema and XSD! If you remove namespaces from the instances completely and use a CAM template as the (optional) way to add semantic context everyone wins! Then if you need to unravel what amounts to the dictionary side of XML - you reference the CAM template and it tells you contextually the semantics of the item you are interested in using XPath referencing and rules.

This decoupling is a no brainer in my opinion - and especially as CAM templates let you automatically generate domain dictionary catalogues of components, OWL and HTML5 forms directly - using XSLT transforms - that you cannot do from the XSD equivalent.

James, continuing the thought of MicroXML and OASI...

2010-12-30T23:16:17.576+07:00
James, continuing the thought of MicroXML and OASIS CAM - have speed read through the comments - one thing I have long found troubling is the "let's cram everything into the instance" mentality that rapidly becomes angle bracket coplexity. By separating semantics into a template you can dramatically reduce what is being transferred on-the-wire to the bare content essentials and let the template then provide heavy lifting on parsing and interpretation nuances and even repetitive content structures and detail.

Someone mentioned audience for all this - I've been working with the NIEM community with CAM - targetting making everything dramatically simpler to do compared to XML Schema. When you give developers simpler more intuitive and robust ways to implement XML-based information exchanges - everyone wins.

Also simpler should not mean less capable. The trick here is to deliver simple yet strong functional capability that matches 95% of business information needs; more than an 80:20 approach - but less than 100% of all possible needs; its that striving to cover off the last 5% that adds 200% of the complexity. It's OK to say - in MicroXML we are just not going to worry about certain aspects of markup complexity - and catalogue those items as "not supported" so people understand the design limitations selected.

Thanks, DW

James, I'd like to see also how we can tie the...

2010-12-30T22:50:56.624+07:00
James, I'd like to see also how we can tie the OASIS CAM template work into this as well.

MicroXML and CAM seems like a very strong match...

We're getting ready to do CAM v2.0 in 2011 - so adding MicroXML support would be a natural.

Thanks, DW

John Cowan: I think a key feature of JSON is that ...

2010-12-29T17:03:05.982+07:00
John Cowan:
I think a key feature of JSON is that JSON data contains its own metadata to define/declare its datatypes (without the need for a schema). If MicroXML could match this then there would need to be a way to add corresponding datatype-related metadata to the XML, wouldn't there? If all of the JSON data is mapped to MicroXML elements then maybe that can be done using attributes to contain the type-related metadata. Could the MicroXML (mapped from some JSON) contain metadata about the type of an element's text content (without the use of a schema)? Might it need reserved attributes, etc?
But how would the MicroXML instance contain metadata about the type of an attribute's value (without a schema)?