Subject: Re: Version 0.9.0
From: Justin Bradford (justin@ukans.edu)
Date: Tue Apr 25 2000 - 20:37:09 CDT
On Tue, 25 Apr 2000, sam th wrote:
> Option two - what I proposed in the first part of the email. It looks like
> this.
>
> <field type="list-label" level="1" style="Capitalized List">A</field>
>
> All the logic is in the field tag, so this is an improvement over 1.
> However, <field> has been given lots of extraneous attributes that only
> make sense in the context of lists. In addition to being unclear, this is
> likely to lead to namespace collision (for example, style="..." here means
> something different than <p style="..."> ) The more fields we have, the
> worse the namespace pollution gets. for example, this might be a page
> number -
But the "lots of extraneous attributes" is a feature common to all field
types. We'll need to store entirely different data for time/date, simple
automation, lists, page numbers, document information, author information,
etc.
It's a problem we'll have for each, and the plan was to use generically
labeled attributes. The usage of the attributes would vary by field, and
the implementation would do the right thing with them.
> There is no good way to specify these requirements in XML.
We might need additional structural information in the attribute.
I suspect a CSS style-like format would be satifactory.
ie.
<f type="page-number" options="starts-at: 2; show-even: false">
> Option 3 - my proposed solution. looks like -
>
> <field>
> <list-label level="1" style="Capitalized List"/>
> 2
> </field>
Having a separate element complicates the piece table and formatter
considerably, and we can encapsulate the list-label field information in
the normal field element. If we can't then fields are broken. If you are
suggesting that list-label's should be distinct from fields, to allow, for
instance, multiple list-labels within a single field, then it's a
different story. I don't think we need that flexibility, however.
> This has the following advantages
>
> - - easy to specify in XML / easy validation
We can put basically the same information in the field attributes.
> - - no namespace pollution
We'll want to use generic attribute labels for fields anyway,
so this isn't as relevant.
> - - makes relationships clear
You have me there. The XML description of the data is not as clear with
option 2, as the meaning of the attribute values depends on the field
implementation.
> This advocay may just be the XML geek in me attempting to impose my
> standards on everyone else, but I really think that it has advantages.
I think the problem here is that we're using XML simply for storage. We
don't (exactly) use the XML structure internally. It's used to construct
the piece table and formatter which does things a bit differently.
For example, the proposed field implementation doesn't really have a field
container. It behaves as though an independent object and the "contained"
runs reference this object for certain behaviors.
One could make a very convincing argument that the word processor should
effectively be a DOM tree, with a page layout view of the contents. That
is not, however, what AbiWord does.
Justin
This archive was generated by hypermail 2b25 : Tue Apr 25 2000 - 20:37:15 CDT