Wdowiak on the subject of RelaxNG.
(1) Greg suggests that the readability is down to the non-XML syntax.
I believe that while this is definitely a contributing factor, it is far from being the whole store. I find the XML notation almost as easy to read but more difficult to write. So, I write in RNC and trang (a new English verb:-) to RNG.
Contrast the compact syntax of RelaxNG with, for example, Eric Wilde's compact XML syntax for W3C XML Schema - xscs.
As the comments to that article show, a new syntax does not address the fundamental complexity issues of W3C XML schema.
I'm quoting Eric here:
- "xml schema's complexity may be a problem for a number of (potential) xml schema users, but since we only wanted to create a new *syntax*, i think it's not appropriate to criticize the syntax for the complexity. any syntax that does not hide certain facets of xml schema has to expose xml schema's complexity."
Greg goes on to talk about the dual lexical/sytactical nature of XML and talks about cases where XML provides a convenience for programmers (who don't have to write the bottom layers of language parsers) at the expense of humans who have to read/write the stuff.
Greg asks "where to draw the line"? I wrote about this in RDF and other monkey wrenches where I used the phrase "semantic shadows" to refer to the idea of a human syntax and a separate, isomorphic, automatically generated XML representation for any
language. Examples: N3 in the case of RDF, RNC in the case of RNG etc.
We can get the best of both worlds. For any syntax that requires human read/write grokability, create a human-oriented and a machine-oriented notation. Use *text* for the human oriented notation and XML for the machine oriented notation. The two notations must be isomorphic and automataically convertable from one notation to the other. Programmers
needing to work with the notation work with the XML and thus avoid having to deal with the lower layers of language parsing. Humans work with the compact syntax.
Using some simple timestamp algorithms such as the one python uses to turn .py into .pyc would allow the human or the XML notations to be edited with background "compilation" to the other syntax happening as required.
So where to draw the line? I think it is worth looking at an isomorphic compact syntax when the density of repetitive "scaffolding" markup becomes an inhibitor to cognition.
Quoting Greg here:
- "Perhaps in such cases a 'dual' approach is an optmal one? (an underlying implementation always XML + a human/programmer-facing readable extra such as the RelaxNG's compact syntax?)"
Yes. Absolutely.
(2) Greg asks
- "The RelaxNG syntax seems to miss the inheritance mechanism. Would you see that as a limitation for designing the document-centric world?"
No. I would see it as a positive contribution to the document-centric world. As I mentioned in a recent post linguistic determinism is alive and well in artificial languages. If a language provides idioms that allow you to think in OO terms, you will see things in OO terms.
Neither inheritance nor encapsulation of data/behavior, esposed by OO are key idioms of document-centric integration.
Greg says
- "More specifically, I feel that OO-like modelling approch is an excellent one for specifying the relatively primitive building blocks of the documents (such as address, customer, and what have you). As such, it seems to be an excellent 'support technique'."
I disagree here. Even in simple contructs like address, customer and so on, you need the freedoms the XML provides to intermix structure with text, to nest structures and to make structures recursive.
XML frees you from the modelling strictures created by the false dualism between objects and containers and frees you from the horrors of flattening perfectly good business constructs to fit within the strictures of normalised database tables.
A good test for whether or not an application is taking a document-centric or a data-centric approach to data modelling is
*mixed content*. Mixed content cuts to the heart of the document-centric worldview and is famously ugly when represented in an OO-like modelling approach.
Greg says:
"The BNF-like approch seems to suit better the higher-level speficiation (such as an order document) that may more od a real syntax rather than just being a Java-like object/data structure."
I would argue that the grammar based approach works best when applied all the way down. I think switching paradigms from container types (like tables or hash tables) to "native types" (like record/object/integer) is both unhelpful and unnecessary.
Thanks for the comments, Greg.