Cart
[Home] [By Thread] [By Date] [Recent Entries]
> I've heard that namespaces is a bad design several times, but > I cannot understand why it's a bad design, simply because I > don't know what a good design is. Namespaces is all I know, I > have no reason to believe it's a bad design unless someone > point me to a good design, are there any? I agree, it's much easier to say what's wrong with the current design than to propose something better. Though I don't think it would be hard to design something better if backwards compatibility were not a constraint. The two fundamental problems with namespaces, I think, are (a) the overloading of attributes to act as namespace declarations. This has little negative effect on XSLT/XQuery which ensure that the two things are handled quite differently, but it confuses users and makes some interfaces, like DOM, extremely messy. (b) the confusion about whether prefixes are significant or not. All the other complexities follow from these two bad decisions. A simple clean design which would avoid these problems might be as follows: (1) elements and attributes have hierarchic names, for example org.fpml.invoice, which can always be written out in full if so desired (2) if abbreviated names are wanted to reduce verbosity, then at the outermost level of a document (perhaps in the internal DTD) prefixes can be defined <!PREFIX f = org.fpml> allowing the element name to be written as <f:invoice> with the clear understanding that the prefixes are for authoring convenience only and do not form any part of the data model; they are not visible to applications, which only see the expanded name (as a simple one-level name); they are recognized only in element and attribute names and not in content. If it had been done this way, I think about 30% of the complexity of our specifications would have been avoided. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
