PS: ... I still think that "super-documents" are an interesting concept, but I begin to understand better that your posting points in a different direction, and perhaps even better understand your use of the term "web architecture". How about this. Web architecture is built on the concepts of resources and their representations, as well as URI-based links. XML technology is built on the granularity of documents=resources and URI-based document access. Your words, on the other hand, suggest an alternative basic unit, which might be called database, if this term were not so loaded with fixed (and contradictory) expectations. A new term would be better, let's content ourselves for the moment with the term "info system" (or "info base"?) - at any rate a larger (and typically more complex) unit than conventional documents - essentially a system.
The concept of "super-documents" has a place in a resource-centric context, there is much to be gained by it....
... BUT what I now understand your words to mean is that there may be an alternative, which is not resource-centric, but "system-centric". This unease I immediately share when remembering the fact that in spite of the huge merits of XML technology, it seems almost always out of the questions to migrate large-scale enterprise data from relational databases to XML. Is this not exactly because XML is too resource-centric in order to provide the fluid interconnectedness which relational databases after all provide?
Wrapping up: super-documents are an interesting extension within a resource-oriented context; but they would probably be too static and not scalable enough to provide the "system experience" which we do miss when dealing with XML, at least when we think about managing huge and frequently updated data stores. Yes, this
packaging of bookings into documents is questionable.
And perhaps the core of the matter is really the concept of linking, and the way it's presently tied up to URIs. Should we not have a more key-like traversal experience, instead? There might be alternatives based on collections and within-collection keys. (For example, "documents" might be addressed by QNames combining the collection URI and the within-collection key, like "client:c809712".) And I would be glad if you took an active interest in this fundamental problem and perhaps came up with new approaches.
Von: Michael Kay <mike@saxonica.com>
An: "Costello, Roger L." <costello@mitre.org>
CC: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Gesendet: 10:15 Mittwoch, 14.August 2013
Betreff: Re: [xml-dev] XPath and a continuous, uniform information space
On 13 Aug 2013, at 23:18, Costello, Roger L. wrote:
Third, resource boundaries do not impose a resistance to navigation: the effort to enter a different document is not greater than the effort to move within the same document.
I've always thought it a weakness of the XML model that resource boundaries were visible at all. In your example, the calls on doc() to cross resource boundaries are explicit.
When you're designing an XML database, deciding what information to put in one document can be a major headache (e.g. if you're managing hotel bookings, how should hotel bookings be grouped into documents?) I've always felt it shouldn't matter:
there should be a single data hierarchy in which the resource boundaries are totally invisible.
I'm sure that's achievable, but the web architecture doesn't encourage it. For example, intra-document linking is handled quite differently from cross-document linking; most schema languages can only validate one document at a time, not a collection of related documents.
Michael Kay
Saxonica
