Raul Miller <[EMAIL PROTECTED]> writes: > Overall, it looks good to me, but note that mostly what you've defined > here is a framework for localizing changes to a particular region of > a document. > > Given this point of view, I'm a little dubious about declaring that > certain >>kinds<< of document elements are always structural or always > floating. In my opinion it makes more sense to simply define an > attribute which may be put on a floating element, and let the document > author declare what can float.
Me too. But unless we then want to limit the system to handling simply one DTD, or just the set of DTDs we modify to have these attributes, we should use an SGML Formal Architectural. SP supports this and it would even make the building of our parser interface and tree comparison code easier. I didn't want to introduce Formal Architectures, because I wanted to keep the complexity down, but I think that if we do statically define wether an element is always floating or structural we severely limit the usefullness. In that implementation we simply can modify the prolog to indicate how the translation to the LI architecture should be done, and allow the author to specify the behavior of particular instances of elements with attributes. This allows us to default to same suitably general behavior for structural and floating elements, but would allow a anal-retentive documenter to do some very particular specifiction of the LI structure of the document, possibly including ordinality and cardinality. The drawback is this may tend to get a bit complex, hehe. > As I understand it, this "floating element" concept comes from the idea > that illustrations and sidebars should be near the text that refers to > them but that their placement is a layout issue, not an editorial issue. > However, it can quite easily happen, for example, that a table is a > part of the text, and for it to make sense it should appear between > two paragraphs. Correct, but the creator of the master document cannot assume that his assumption about the relation of the text to the paragraph is the same across all languages being targeted for translation. For all he knows a vertical layout is used for some language, and tables and images are printed in a seperate column to the side. So the previous proposal would have required him to make P and TABLE floating for the entire document. This example is a bit of a stretch, but I'm hungry and unimaginative at the moment. > This isn't a real big issue in my opinion -- which is why I don't > want to see us develop an elaborate mechanism for handling it. I agree. I think that we will overload ourselves with complexity if we try and come up with a way of distilling a nearly perfect LI representation of a document that deals comprehensivly with cardinality, ordinality, and containment. We just want a quick way to find out wether or not the documenter A added a new section on feature Y to the document and which translations don't have that feature documented.
