Daniel Dekany wrote: > > Even if that's affordable in your usage scenario (and maybe more > painful for some users), that's still awkward. But it's not the main > point if how much inconvenient it is, if only a little, or a lot. It's > that these inconveniences and other Baroque things are symptoms, > results of a deeper issue, which is that you follow this traditional > way of structuring data (and even that to an extreme level, as you > split a single document to multiple files). Surely it's hard to see > where would you be if you start out from another philosophy from the > very beginning, especially from the point that you have reached > starting out from a different foundation, but I feel inside that it's > not good this way. It's like, you know why is XXE good, and not just > yet another WYSIWYM editor... Because it had a vision, that the hiding > of the XML structure (simulating traditional word processors) is > stupid, instead the editor should build on it.
That's right. Do not attempt to hide the reality. Make it easy dealing with it. > It won't be popular > because it breaks the traditions, but that's exactly why it stands > out, why it can introduce ways of editing. I think good things would > come out from this tradition breaking, reforming way of looking at > things, from this thinking in the true XML way, if you apply that on > the higher granularity levels as well. You seem to stick to (defend) > the way it currently works, and I don't know if how much it's because > of deadlines and other everyday overburden (i.e., you don't miss yet > another thing to rewrite), and how much is it because thinking > preconditioned by habits. This is not the case. See below. > I any case, I think it should be > reconsidered if you want to defend this current approach. I'm pretty > sure it's not right, not on the long run, so it shouldn't be defended, > at least not in front of yourself. If you have no resources in the > foreseeable future for changing this is another thing, but it would be > too bad to fall into the mistake of thinking it's the good way as it > is. Splitting up to files is not hierarchical. Also, the boundaries of > files are rigid and hand-made. XML documents are already hierarchical > with high granularity, and even better, following the logic of the XML > Schema, the information semantic. It must open more powerful ways of > navigation and ad-hoc segmentation building on that. And, of course, > And of course the earlier mentation inconveniences inherently wouldn't > exist. > When we created XXE a few years ago, we had another vision which happens to be similar to DITA concepts. Create a tool which allows to author loosely coupled atoms of information (DITA calls them ``topics''). A document, that is the XML source of the deliverable, is then created using the same tool by aggregating several atoms of information. Note that all this has nothing to do with the physical representation of the information: XML, its structure, the schema, files, etc. When I need to write some documentation, I don't say to myself, let's split this document in 12 chapters because XXE does not work too well with large documents. I say to myself: let's write an atom of information which explains for example, the difference between authentication and authorization. We are convinced that this bottom-up approach, focused on the topics rather than on the deliverable, is the good one. We don't see any other approach which would allow a team of technical writers to author the most complex documentation (e.g. the documentation of a plane or a nuclear power plant). XMLmind XML Editor ZZZZ Edition, which is tightly coupled to XMLmind Document Repository and which initially, was heavily inspired by Wikis[*], is our attempt to prove that it works. We all know here at XMLmind that the risks are great to come up with a unusable piece of crap. However, we would really like to see if it actually works. --- [*] XMLmind XML Editor ZZZZ Edition + its XMLmind Document Repository is *not* a Wiki. A wiki is at the same time the authoring tool and the deliverable.
