Peter Clifton wrote: > The real lesson I think we could learn from XML is decent name-spacing > for extensibility.
But it's not free and done. You still need to parse this, save in memory and write back to disk when saving. And this means you will likely need to use the XML tree as your internal data structures. I'm not sure if namespaces not consciously supported by PCB source code will be used for anything. There is also the thing about backward compatibility and ease of extension but once more the semantics of supporting older versions with newer files are something you must do; not something you get for free from XML. In this regard XML with namespaces is not something way better than any other resonable format (like s-exprs with a deterministic writer or netstrings). The only place where I have seen namespaces really shine was Jabber/XMPP because the produced data got consumed immediately and the win was that you could ignore what you didn't understand (like with HTML) while validating the rest (unlike HTML). >> No, please don't. Please make it so that I can still use sed and awk >> to edit my layout. I once used gnumeric to do parts of a layout. > > Admitedly editing poses a problem, your parsing tools would need to be > stateful. > > XML (and other multi-line free form formats) are write-easy, > read-complex. > > You can still happily write out an XML file with printfs, awk, etc.., > but to then re-read a file, you would need to either: > > a) Use a proper XML parser > b) Have some guarantees from PCB about the white-space formatting it > uses when saving. > > a) isn't totally abhorrent, if you assume this parser lives in PCB, and > PCB were to expose a swiss-army-knife's worth of actions for scripting > with. > > As DJ said, at some point we may need to go multi-line, and that means > more parsing complexity. In any case, we need to "invent" this new > format from a data-structures POV. Regarding syntax, if not XML, then > we'd need to invent our own syntax and parsers too. A is reasonable and B is probably a good idea. I think that A will be good for serious tools while B will allow one-liners. Of course the XML as base means we may trivialy map it to s-expr or any other reasonable data format (is't just trees; nested lists). Why do you think you will need to go multiline? Probably one line per element/line/pad would not be a problem. And for easier inspection you could indent it with xmlint or even some GUI XML editor. -- regards, Jakub Piotr Cłapa _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
