Key phrases:
- "Comatose lists"
- This is a cathedral, not a bazaar
- There's exactly one way to do it
- The Wrong Side of 80/20
Lots of good ideas waiting to be stolen. Stay tuned for a Common Lisp adaptation.
2007-07-01
There's exactly one way to do it
XOM is a DOM alternative written in Java and for Java -- in contrast to DOM, which feels wrong in almost every language.
Key phrases:
Lots of good ideas waiting to be stolen. Stay tuned for a Common Lisp adaptation.
Key phrases:
Lots of good ideas waiting to be stolen. Stay tuned for a Common Lisp adaptation.
Subscribe to:
Post Comments (Atom)
4 comments:
XOM is particularly interesting not just for the API, but the extreme care that Eliote Rusty Harold has spent on making it correct. Perhaps you could somehow adapt the extensive test suites as well?
Looking forward to contributing to this effort.
Absolutely. Stealing parts of the test suite will be a good idea.
All in all, Java and Lisp are too different for a direct XOM translation to make sense. So this isn't going to be "CL-XOM", but rather a new API inspired by it.
That also means most tests will not be a direct translation. The basic algorithms that need to be tested are exactly same though (like well-formedness checks and namespace handling).
It sounds like it's a bit too correct:
XOM is the only XML API that makes no compromises on correctness. XOM only accepts namespace well-formed XML documents, and only allows you to create namespace well-formed XML documents. (In fact, it's a little stricter than that: it actually guarantees that all documents are round-trippable and have well-defined XML infosets.)
Namespaces are not part of the core XML 1.1 specification, so it sounds like this means that there is a set of valid XML 1.1 that I cannot generate with this tool, as it won't let me drop the optional namespaces.
(Now granted you usually want them, but perhaps not always.)
> It sounds like it's a bit too correct:
That's right.
But it is worth having a data model designed for namespaces, since that is what today's XML-related specifications assume anyway.
For the few occasions that you have to work with documents that are not namespace well-formed, I would suggest sticking to DOM.
The DOM implementation in cxml isn't going away, I can promise that! I just hope to offer a better alternative in addition to it.
Post a Comment