Dave Pawson wrote: > Nor I. I think the level of support is indicated by the lack of interest since > the 2005 traffc?
It is a fundamentally hard problem with a number of conflicting interests, ie., no obvious technical fix. Think of the document type/architectural form as a protocol or interface description. It is hard to design robust protocols, and versioning of protocols is really hard, because a lot of real-world trade-offs are required. Needs differ wildly; from causual narrative XHTML web pages to UBL business transactions with significant financial or legal consequences. Apart from what different schema technologies are supposed to do technically, and how much trouble they are to process, they constitute a contract between the producer and the consumer of the document. There is a real need for a way to be explicit about how a document is supposed to *behave*. Things get absurd if you expect XML documents to be completely self-contained. The document does not do anything all by itself, it can not represent anything without being consumed/processed in some way, If you do business transactions by exchanging massive amounts of XML documents, the need to link a document to the intended business semantics is pretty obvious. Witness OASIS UBL [1]. A large part of UBL consists of code lists that specify codes for countries, currencies, and so on. If you do news syndication by exchanging massive amounts of XML documents, you actually have very similar problems: how to relate news items to relevant categories that allow automatic routing and processing, see e.g. [2]. If you do narrative document processing in a confined environment, you might be able to handle the problem on an ad-hoc basis. But even here, it is a royal PITA that each processing tool uses its own PIs/heuristics/magic. [1] http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html [2] http://www.iptc.org/NewsCodes/ Kind regards Peter Ring
