Wednesday, July 30, 2008, 4:25:31 PM, Hussein Shafie wrote: > 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.
Yeah, but I think it's not even that kind of case. It's that SGML (the precursor of XML) was designed to write documentation as a primary goal (as far as I know), and as far we are talking about the *info-set* (as opposed to the textual XML source) it is indeed practical for that. It's designed for that, so the info-set shouldn't be hidden, but not many has grasped that, it seems. >> 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''). Luckily that goal doesn't clash with the things I said, but also, note again that widening your goals is not inherently a bad thing either. Rather maybe it's something that worth inventing into. > 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: Yeah, that was exactly my point too, that it shouldn't do anything with that... but in the case of XXE it does. Like, if I have the link target in another file, I don't see it in the list of available targets, and so on. Just because I'm working on a certain little piece of the whole at once, it shouldn't be so aggressively and stiffly torn out from the whole. There is hardly any ground for doing that, other than purely technical and historical reasons of course. Also it's not transparent that I have split the stuff to various *files*; if it were transparent, nobody would want to split it on the first place, except for the sake of other tools like version control and like. But even then it still should be mostly invisible from XXE that I have multiple files as the physical storage. The information you have is a big XML node tree, and maybe you focus only a chosen sub-tree of at once, and maybe some sub-trees of it are edited by other persons in parallel, etc., but it still should give the illusion of a single big tree (in almost all cases, that is), because that what it is, that's the truth, the information you have. I'm pretty sure that if you try to evade this, you will end up with some awkwardness, it's just guaranteed. So instead of stiffly spiting up the document, the editor should be designed so that you can effectively navigate in huge trees, and focus on chosen parts of it (like looking at only a certain chapter of a long book, so the vertical scroll bar remains useful). And by this you automatically support non-DITA-like stuff as well; even if it wasn't a goal, I think you wouldn't mind that. :) > 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. For technical documentations it's the good one more often that not, and I see where you come from, but it doesn't require all that going on in the case of XXE right now. You know, creating multiple files, then an including file, then suffering with that the individual files act like if they have no context... etc. > 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. -- Best regards, Daniel Dekany
