Cart
[Home] [By Thread] [By Date] [Recent Entries]
I think there are three distinct cases. The first is the declarations used for namespaces on elements and attribute names: the subject of the Namespaces in XML spec. This took multiple thousands of emails last time, so good luck on it this time. The second is the namespaces used for Qnames in element and attribute values. XSLT went one way, but I think it is the wrong way because it fudges the difference between data and markup. Schematron has explicit elements and this has been very smooth: developers don't worry about default namespaces, they only need to look in a single place. The third is that the role of namespace is challenged by emerging maintenance requirements. The generation of schemas developed without version attributes now face the challenge of how to cope when they need a major version upgrade, and namespaces are the obvious and (I think) correct thing to use as a slicker kind of major version number. (It is not that I am trying to say that namespace = schema, however namespace = major version = schema family or base schema is OK.) The rub is that XML now is used for software that is very far from the SGML legal-military-industrial publishing case, where the correct response to invalidity was rejection of the document. A hallmark of small-o office document systems is the need for graceful degradation: you want as much as can be retrieved. Our current namespace infrastructure, such as XSLT, has no story about how to cope with this kind of thing. It is a real challenge for standards developers in the office area at the moment. I worry that our schema languages and normal XML technology do not provide an adequate foundation for this kind of thing, dramatically decreasing the value of using XML at all. Of course, there are bits and pieces: XSD has its type derivation mechanism and the new alternative mechanism, but it is at the node level not the namespace or schema or document level; Schematron has phases and parameters; ISO DSRL allows renaming; RELAX NG allows notAllowed which can switch in and out; OOXML MCE allows alternative sections in the same document where the system chooses the optimal version. But these all fall over in the most common problem cases: I have last year's software and I get sent a document with this year's namespace/version, or I get sent a document with 10 years-ago's namespace/version. The document itself needs to carry around some metadata to say which what the relationship between its namespaces and previous ones are (e.g. namespace X is a subset/superset/dialect of namespace Y) in a way that allows an application to make a good stab at figuring out what to do, if that is what the user does. OOXML has this problem right now; ODF has it also in proposals to consolidate attribute names; HTML has had it for a long time, with all the different dialects. May I be cynical? I expect that discussions on namespaces will focus on the first, since they are all different W3C WGs. And consequently the needs in the third area, which is surely just as important as HTML since it involves spreadsheets as well as literature, will be pushed aside and ignored. The SML discussions here a decade ago were a call for more simplicity which, by focussing XML-DEV kind of people's attention away from the actual standards agenda, actually promoted the greatest increase in complexity in SGML/XML's history: XSD. Please lets not make the same mistake again, even though syntax is so amusing. The big items on the standards agenda at the moment are HTML5 and ODF/OOXML (both what they are and what they need in the way of enabling standards.) Why not hop out of the armchair and get involved in those? Cheers Rick Jelliffe
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
