Raul Miller <[EMAIL PROTECTED]> writes: Thanx for the input Raul.
> Craig Brozefsky <[EMAIL PROTECTED]> wrote: > > 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. > > Can you talk a bit about the nature of this limitation? I just don't > see it as that big of an issue. It means that the LI semantics of an element are static, and cannot be modified by the author as they see fit in order to better represent the LI portion of the document for each instance. This is not something that I think would be a real world problem with any frequency. But if we're trying to create a system with somewhat complete capabilities, I would want the ability for the author to give some indication of the LI properties of a particular instance of an element, without having to change the LI properties of all other instances of that element. I guess the tao suggests we shoot for "real world", instead of conceptual completeness 8^) > I don't buy this [yet]: If the layout is that different you can't rely on > the document structure being the same, either. You could rely on SECT and CHAPTER structures remaining the same, while relationships between smaller structural components change(P to TABLE as in my example). Tho, this is why I suggested the ":language" property on the definition of the LI floating elements, to indicate which set of languages it's significant for. Actually, the system I'm proposing is not really designed to enforce the type of relationship you suggested in that example with the two paragraphs around a table(or was it image). That is an issue of ordinality of particular instances of floating elements. I do not think that is a relationship that we want to try and capture. > Anyways, Debian documents tend to have a rather straight-forward > structure without a lot of fancy layout -- we have a practical need > to support a variety of media, and you just shoot yourself in the > foot if you try to get overly elaborate about this. I would like to keep it as simple as possible, which is why I left out modification of LI properties of particular element instances from the original idea. We've just gone back and forth about wether or not we feel that giving the author that control is neccesarry, and wether it's worth the added complexity. I'm leaning towards the LI properties of elements being static, meaning that the element has the same LI properties everywhere it appears in the document, and this cannot be overridden by the author on a per instance basis. This saves us from the Formal Architecture stuff, and I think it hits a sufficient part of our "real world" cases. > In my opinion, this is a portability issue, and you can't sanely tackle > portability issues without real examples of the issues. The "real example" of choice would IMO be to proceed with a lightweeght implementation of this and try and see how it fits the workflow of a real translation. Comparing two static documents is not going to help us much. The basic idea I have put forth of extracting a tree representation of the LI structure of the SGML document is drawn from the work done by The SGML technologies Group on the European Union's Budget publishing process which has over a dozen target languages and a very complicated document structure. Again, thanx for your input.
