Thanks for having this extra thread. I think this thread is much more important than starting to design something already. > Issues with the XAR format > ====================== > > * XML is not an easy to edit format and doesn’t allow use a specific > editor to edit content > * XML also requires content to be XML-encoded and thus is really not > easy to make modification (there’s a risk of breaking the XML easily) I completely disagree with these two statements. XML is easy to edit and is supported by very very many editors and IDEs. It can also be validated. XML can be written in a very elegant and readable fashion if you care for it. Generally however, XML is produced form other structured information in a way that does not help readability. > Can you see more issues? The problem is how we put *everything* into XML. (you get the same horror if you use Caleb's tools xardump and do not tune anything: the resulting javascript is horrible.) > Use cases for an alternative filesystem format > =================================== > > (some UC taken from > http://design.xwiki.org/xwiki/bin/view/Design/DirectoryStructureforXWikiApplications) > > * UC1: the structure should be (as) easy (as possible) to navigate in > an IDE style view > * UC2: it should be easy to add content (a new script or attachment on > an existing structure). It should allow using specific editors for > different content types, e.g. if a page content is in markdown, it > should be editable with a MD editor, js and css should be editable > with web editors, etc. UC2.1: Attachments should also be present as standalone files. > * UC3: It should be possible to build a packaged version of the > sources with Maven > * UC4: It should be possible to import the packaged version into a > running XWiki instance > * UC5: It should be possible to export a portion of a running XWiki > instance in this format > * UC6: This format should be able to fully replace the XAR format . > The new format should support at least all features supported by the > XAR format (versioned, etc). Note: XE will need to be refactor a bit > so that the XAR format can be swapped out by introducing extension > points/APIs. The idea would be to deprecate the XAR format and > introduce this new format instead, and the 2 formats should be avle to > cohabit next to each other in XWiki. > * UC7: When importing in a wiki and exporting again (without making > any change in the wiki), it should generate an identical structure and > content, with no difference. I do believe that UC7 is not doable in full generality.
Any more? UC8: the core representation should be using a syntax that is widely spread and completely specified (i.e. we should not invent another syntax for this) UC9: the system should make an archival process a widespread practice, in the form of zipped files probably. UC10: developers should have the discretion to decide when a component needs to be in a separate file or not. That is, small text fragments and even small attachments should be includable within bigger files UC11: there should be the possibility to share content of a file between several files or components (e.g. creator elements) UC12: (transformation) simple search and replace operation should be supported by the build mechanism, especially when dependencies are followed. UC13: it would be good that the format can be specified by a grammer against which one can validate (e.g. RelaxNG) Paul (FYI UC10, UC11, and UC12 follow the architecture recommendation to be composable vs contextual so as to give us greater flexibility) _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
