Sidecar.xml first generation

Question

Johannes granted us with the excellent : http://projects.nordsueddesign.de/sidecarxml/ so that we can organize and easily manipulate elements of a large publication.
The thing is it requires a "first time generation" which seems to have to be done manually, filling each folio name, description, etc.
Basically, this xml manipulation is done inside the Folio Builder panel, or the Folio Producer website. And it's "invisible" to the user.
I don't see, and think we would require, an export option once a folio is organized, to generate this very first xml.
Second thing is this tool is hosted freely by Johannes, when i suppose it should be hosted directly by Adobe, at the very least mentionning the creator and owner of this priceless tool.
I also saw a discussion here http://forums.adobe.com/message/4031557 and wonder : We can update the sidecar xml alone. But it seems to require to process again all the present data, images, and send again online, when it only has to change properties and the order of the pages. Shouldn't there be a way to update ONLY this meta file in the folio/different articles ? Just thinking of the process and bandwidth for a 300MB folio when a 50k xml is all that changed…
PS : we need a "vote for ideas" option somewhere here, no ?

Answer 1

thank you Franck for your nice words. I like that I could help a few people
out with this generator that I initially only made for myself.
now that we require renditions, sidecars are more important than ever.
normally, I create everything in the sidecar at first, don't edit metadata
in the folio builder panel/organizer.
Bob Bringhurst somewhere mentioned a possible "export" function where you
can then transfer the metadata, wich is on some roadmap.
but the requirement of such a file is wrong at the first place. instead of
duplicating a folio two, three, four or five times (iPad2,3, Android,
iPhone 3,4) this should be an integrated process.
a folio should have defined "targets" inside: iPad, retina, android. and
when Adding an article, all required 'internal renditions' should be
generated automaticlly by upscaling and/or picking the right alternative
layout.
I think this would be the correct architecture for renditions and it is an
approach we see by many multi device workflows (especially iOS app design).
but now I am turning this thread into a discussion about renditions.
sidecar.XML is good, but does not cover all things, like preview files or
article format, so there might be an improvement as well.
the code of my sidecar generator is also available on github for everybody
to grab, improve and host (or check changes back in).
—Johannes
(mobil gesendet)