On Tue, 2008-02-19 at 00:12 +0100, Jakub Piotr Cłapa wrote: > 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.
PCB supports plugins, so there is a reason to want namespaced data in the file. > 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. The view that XML will cure the world and avoid the need for data-structure design is an idea which has harmed XML lots, and one I'm trying to avoid bringing across here. > 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). If you namespace the s-exprs, its another valid syntax. Deterministic writing is the key for any more complex format. > 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). The amount of bad HTML browsers accept was IMO a stupid design mistake in HTML. Far better is defining a standard syntax (allowing expansion), standard semantics, and dropping a big fat "ERROR" page if the syntax or defined semantics are violated. There would be fewer bad web-pages out there if this were so! [snip] > > 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. I haven't done a data-structure design for PCB or any other layout code, however I got the feeling the amount of information which "might" be added could potentially be quite large. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
