Re: [xwiki-devs] [Brainstorming] Use cases for an alternative filesystem format (alternative to XAR)

I probably didn’t use the right words because that’s the reason why I think that's you started the xinclude proposal :) AFAIK you started the xinclude proposal because you wanted to be able to edit content with specific editor (js, css, etc)… which is exactly what the second part of the first point is about. Let me rephrase the first sentence: * XML is not an easy to edit format for human beings (it’s very verbose and easy to make mistakes: missing encoding, etc). It’s also very hard to edit with a plain text editor. As for the 2nd sentence, I don’t see how you can disagree since it’s a fact... What you’re saying is very theoretical. The practice (that we’ve had for 10 years of using the XAR format) is that our XML format that is hard to edit and can break easily (as was proven numerous times by our committers and contributors). It’s actually so dangerous that we’ve had to develop a process which goes like this: * Never edit the xml directly * Always import it into a running XWiki instance, make the modifications there and export from the wiki into XAR * Then unpack the XAR into the source directory and run mvn xar:format to go back to the original format. Nobody is using a pure XML editor with validation. We are all using Java IDEA (IntelliJ IDEA, Eclipse, etc) and they all allow you to edit XML as plain text and that’s what we’re doing. No developer I know of is using an XML editor in a structured way (just too painful and complex to navigate the structure). (see below) Why not, this is what we have with the XAR format actually and UC7 is actually already contained in UC6 (but it’s better to be explicit)? This is not a requirement for me. The syntax should be easy to write into, especially using a plain text editor. YAML for example is a perfectly valid syntax for me. That’s UC3 for me. I hesitated to put ZIP in the requirement for UC3 since I didn’t want to limit us to that but it’s probably going to be zip anyway. I don’t agree with this one. I’d like convention over flexibility, i.e. a fixed format on which tools can easily build upon. This is similar to Maven vs Ant. This is why in my proposal for a format I’ve proposed fixed file names. Allowing discretion means everyone will do it differently and we’ll need to define best practices and best practices are hard to enforce and always cause problems. I wouldn’t phrase it this way. I’d prefer to say that it should be possible to apply default values to missing elements in metadata. The way I see this for example for the format I’ve proposed in the other thread, is by having default properties that can be put on the filesystem, for example in default.properties file) so that when an element is missing the default would be used. Now I’m not sure we want this requirement and for me it’s an optional requirement and not a mandatory one. It makes it much harder to develop an exporter. Could you explain more, I don’t understand? I don’t agree in the way it’s phrased since it’s too limiting. I’d change it to: it should be possible for the packager tool to validate the content (what xar:verify does right now but that could be extended to verify that the required metadata are defined). I don’t think we need a formal grammar. The important part is that we have validation. Thanks -Vincent