OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Numbering spec


Hi David,

I don't see how moving the attribute from text:list-item to text:list changes anything?

Additionally I don't yet understand what kind of list description you need which can't be encoded using the style-override approach?

~Florian


>>> David Faure <faure@kde.org> 11/21/06 9:26 PM >>>
On Tue Nov 21 2006, Florian Reuter wrote:
> Today every <text:list>….</text:list> definition only contains one “counter domain”, i.e. whatever you do its “one” list. Please note that the <text:numbered-paragraph> is just a different encoding of <text:list> and <text:list-item> elements. I use the <text:list> encoding, because I think my view can be better explained using this encoding.
> 
> Again; every <text:list> element declares the domain of one list.
> The first idea we had by introducing a “list-id” element would break this. Then a <text:list> element could contain several lists. To state it different; the list-id approach makes the style of a list “fix” and the counter domain “variable”.
That is true. We could however move text:list-id to <text:list> instead of putting it at the text:list-item level like in your example.
This way, we wouldn't break the idea that "every <text:list> element declares the domain of one list".
(With still, like today, the possibility of having multiple text:list elements refer to the same list)

> The “style-override” approach is the opposite. It keeps the relationship between <text:list> and the domain intact, but allows to apply different styles to it.
The list-id approach (with list-id being an attribute of text:list) allows that too, doesn't it?
I would then write:

<text:list list-id="MyList">  <!-- although in this example we don't really need an id anyway, in my opinion; this is only useful if breaking it into multiple <text:list> elements -->
<text:list-item>
<text:p>Main Chapter</text:p>
</text:list-item>
<text:list>
<text:list-item>
<text:p>Foo</text:p>
</text:list-item>
<text:list-item>
<text:p>Bar</text:p>
</text:list-item>
<text:list-item text:style-name=”Alphanumeric List Style”>
<text:p>Some kind of annex in this chapter</text:p>
</text:list-item>
<text:list-item text:style-name=”Alphanumeric List Style”>
<text:p>Another annex</text:p>
</text:list-item>
</text:list>
</text:list>

> Regarding the list-id approach and WW its simply the case that
> a) every WW doc can be mapped to lists with list-id, but
> b) not every list with list-ids can be mapped to WW
> So my concern is to have a roundtrip problem here.
> 
> E.g. you can specify lists of the form
> 1.1
> 1.2
> 2.3
> 2.4
> 3.5
> 3.6
> 3.7
> 3.8
> 4.9
> 5.10
> ...
> 
> where you simply assign one list-id to one level.
Hmm that looks very broken and isn't what I want to be able to express either.
If a list-id is assigned to a given paragraph (or list item in your terms), you cannot "assign a list-id to one level"....
After "1.2.", you can only get "1.x" where x can be changed by a style, but you can only get "2.x" after
an item of level 1 to increase the numbering at that level... Neither of us wants to assign list-id to levels :)

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]