On Mon, Apr 10, 2000 at 04:36:04PM +0200, Asger K. Alstrup Nielsen wrote:
> I can appreciate why you ponder this issue, because it's only natural to extend
> the SGML model to the LyX document structure. In HTML, such attributes are often
> modelled as a tag. Consider <b> and <em>. Granted, those nest, so why shouldn't
> we do the same in LyX?
>
> However, notice that there is a second form of specifying these things in HTML:
> As attributes to other tags. I consider this the "correct" modelling of the
> issue. These things are attributes to other things, and they are not tags in
> their own right - they are attributes on hosting environment. And those
> attributes don't nest in themselves. This point is made clear by the absence
> of a <lang> tag in HTML. What you do instead is to set the language as an
> attribute on a container tag.
>
> So, these things are attributes, and not tags that need to be modelled as
> a nesting inset.
>
> Now you might argue that it is possible to nest these attributes in HTML.
> Yes, it is possible to use <span> and <div> to form a nesting attribute
> set, because <span> and <dib> are without other effects.
>
> However, I don't believe there is a real need for this kind of nesting.
I'm aware of the difference between attribute and elements (tags). And I know this
represents different ways to deal with specialization.
I don't think there a prefered way, it is always a matter of compromisse.
Something like templates vs class hierarchy.
When building a DTD there are always these two extreme, too much elements (tags)
and too few attributes or too few elements and too much attributes.
One question before proceeding: what is the nuclear structure in lyx, the inset
or the character.
If defend the view that everything should be an inset. And those inset have
attributes, some very sensible are language, colour (why not ;), id tag,
boldness, and all the present char attributes, and so on.
Of course if not defined those could be inherited from their parent.
I'm clearly assuming a tree structure for the document, and taking this from DOM.
Of course I'm biased towards XML, but what would you expect from me. ;)
The API to navigate the document would be also easier, that would allow
with script language support to write simpler programs.
The interface to the document structure would be homogeneous.
> > > I think it's more important to recognize the similarity with font attributes,
> > > just like HTML does with the <span> property, and thus reduce complexity.
Notice that <span> and <div> are poor man xml, a medicine to take care of the
major illness that is html. (I hope this statement doesn't sound too bold or will
have to pay right to John W. ;) They aren't good examples to take from.
> > In the case of Country (or Name) do you think that it should be implemented
> > as a font attribute (or similar) or as an inset?
>
> As a font attribute. We do not need to support proper nesting of these attributes,
> beyond what is possible with this hierarchy:
Are your concerns related with memory usage?
The drawbacks of my approach are probably this and interface to the user.
> 1. Default hardcoded setting
> 2. Document setting
> 3. Paragraph environment setting
> 4. Paragraph override setting
> 4. Character override setting
>
> Furthermore, we will probably allow "character styles" at some point, and if those
> are allowed to be arranged in a hierarchy, I see absolutely no reason why we should
> use insets for such attributes.
Are those "character styles" configurable from layouts?
> > Important also to this model is the possibility to have insets inside other
> > insets.
>
> Yes, for some purposes, this is important. However, I don't think this is important
> for country, name, number or other of the attributes that we have discussed in
> this context.
>
> I still think the best solution is a character level properties/attribute gadget.
> The reason is that we do not need proper nesting for these things. The kind of
> nesting that would be nice to have, is better implemented in terms of character
> styles.
For me that have to care with the structure, be it with linuxdoc, docbook or a more
general xml dtd that is a perfect nightmare, it makes me want to cry. ;)
> In LyX, we should stick to the attribute part for the first round.
As an implementation issue I can't argue. I'm taking lessons from the xml experience
and trying to see how this fits in lyx.
In case you haven't noticed I don't want to start a endless discussion with no
pratical
outcome. My problem is actual I need those mid range structures badly for docbook.
> If you insist, we can provide a nesting inset *later* that will allow proper
> nesting of these font attributes. I see no reason to introduce this complexity
> at the first round - it corresponds to the situation where HTML only had
> <b>-style tags for setting font attributes.
> Do you see what I mean?
As I have told you I think that it should be a compromisse between the two views.
Behind the hype that surrounds xml there are some lessons that are worth the trouble.
> If you put on one pair of glasses, these things are attributes.
> If you put on another pair of glasses, these things are insets.
I understand your point but believe me things are never as simple as that;)
The question remains what do you call the nuclear units for lyx documents?
> I think we should use the glasses that give us the least trouble,
> and that is without a doubt the attribute glasses.
>
> Greets,
Thank you for the taking you time to answer this. :)
> Asger
--
José
