Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Fri, Jul 10, 2009 at 2:59 AM, Jim Tivy<jimt@b...> wrote: > I would love to hear of some success or horror stories of multi-namespaces > in authoring content. Anyone out there doing this in DITA, DocBook, open > office... some random general xml namespace thoughts: * People not understanding them: of this group, non developers e.g. authors are the issue e.g. spending the cycles to explain to them they must use them without them really understanding (and lets be honest, they don't have to understand them). Most developers I have taught get namespaces after a 'lightbulb' moment which occurs in a time space of hours/days. * Pitfalls: whats in the default namespace ? should I use an attribute or element ? should I embed versioning or any kind of metadata within namespace URI ? I don't want to sound like an XML Namespace 'apologist' but doesn't every concept have its dark corners and nuances to trip up on ? * Doesn't play well with others: the last time I had real issues with XML namespaces was when I had to use DTD's, those memory are starting to fade now. Remember the context when XML namespaces were introduced 10 years ago ... there were some compromises to be made but I would argue that XML Namespaces has performed its primary use case admirably and have been adopted widely. The proof of this success is that anyone in this world can create an XML document and know that it won't collide with anyone else's data ... yes there are caveats with respect to some corner cases that need fixing but in whole hasn't XML Namespaces actually been a success (knowing that I am trivializing some of the details with this last statement leaves a somewhat bitter taste in my mouth to write that) ? * Namespace fixup: This is the one (in the light of my ongoing xproc impl) that causes real pain for me ... as an implementator it can be almost intractable to work with namespaces when it comes to manipulating XML and making sure after some process that the XML has the correct namespace(s) in the right places. We need more libraries to help in this area. * Verbosity: Personally (being a Perl programmer in disguise) I enjoy reducing verbosity in code, but in data I don't care ... there can never be enough verbosity in data (if its meaningful) which is probably why I like my namespaces to mean something to me and others. Some may argue about bloating data formats, etc ... of which most of the issues can be optimized away. * Failure of XML Linking: I wonder if we had a wide spread adopted linking mechanism for XML how this would affect things today ? Wouldn't the problem of groking multiple namespaces in a single document be reduced ? Perhas the real problem is what XML is that its a 'place' where many people doing may different things interact ... for example, we would never expect content creators/authors/etc to directly work on binaries underlying a Relational Database but that's exactly what we do with XML with a surprising little tooling to add abstraction to ease comprehension for those creating content. Ultimately, XML Namespaces are trying to solve a particularly difficult problem of avoiding collision in a distributed environment without the need of a central registry. I think using java namespace mechanism as an example of what is correct makes me cringe ... I know a few years ago that no one would have looked at me strange (in the circle I was in) for saying this, perhaps tooling is so good now that the problem has gone away. I also think that talking about such mechanisms that work for code may not be appropriate for data. I am all for refreshing the concept and taking another look at XML Namespaces, but I don't share the idea that XML Namespaces are a failed pillar of the XML pantheon to be fixed/refactored. Personally I think we need to ensure we fix xml linking first before retrofitting XML namespaces. my 2 euro. Jim Fuller
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
