Steve, you wrote:
"What is "expression-oriented thinking", as opposed to any other kind of thinking?"
I think XML technology is based on the rigorous distinction between representation and information content, shape and value. XPath/XQuery is an expression language - the basic building block of any operation is the expression, expressions are resolved to values, and only the values count. Input XML documents are treated like expressions, too: they are treated as shapes which have a value (a node tree). "Expression-oriented thinking" I call a pattern of thought which regards the distinction between shape and value as a fundamental attitude.
The expression-oriented thinking practised in XML technology stops abruptly at the border provided by XML syntax. Differences of encoding, quote character, use of entities, etc. are abstracted away and defined to be irrelevant to the information content - as long as the text in question is XML. But HTML is "something else", not XML. The standards will not allow to parse an HTML document into a node tree. The prevalent thinking seems to be that text resources defined to encode node trees must be XML text. Is there a good reason, apart from inertia of habit? The more one is aware of the navigational space implied by the sum total of accessible node trees, the less it is understandable why only XML text should be resolvable to node trees. Expression oriented thinking
inclines us to ask: given our model of values (XDM) which can be submitted to technology - why not allow new rules which turn other text formats (say, JSON) into expressions resolving to XDM values?
If expression-oriented thinking were more consequent as it currently is, it would perhaps not stop at the text format border. It would be inclined to regard HTML text and XML text as different kinds of expressions which resolve to the same value space - XDM node trees. To generalize: whatever the format - as long as it conveys information which may be reasonably represented by trees (example: a SQL script), we might investigate the question if unambiguous mappings "format instance -> node tree" (parsing) and "node tree - > format instance" (serialization) are feasible. If the answer is yes, a standardized definition of those mappings & integration into parsers and serializers would effectively pull the respective format into the info space. Some
candidate formats: HTML, CSV, CSS, JSON, SQL.
You also wrote: "XML implies a hierarchical tagged-and-attributed way of life that is not the same as, e.g., the way of a graph database, a programming language, a notation for images, a musical score, etc."
Agreed! The space I am thinking of integrates only those resources which it is possible - and practical - to represent as trees of items. But I feel this is very, very much, and very much is to be gained. The simple fact that web services usually deliver trees of information (XML or JSON, as a rule) is revealing: web services are typical agents to supply us with required information, and if this supply is usually tree-shaped, trees must be appropriate expressions of relevant information in a large amount of common use cases.
Hans
