27 Aug
2016
27 Aug
'16
3:44 p.m.
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/DirectoryStructureforXWikiApp…)
* 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)