As requested by the TC.
Terminology;
* User intent; the numbering information that is still visible in a paper
copy. So not the name of the style etc.
* A list is a set of list-items, spanning several levels. The list is
delimited by the intent of the user.
Requirements;
* Be able to segment all list-items into specific lists. This is used to
unambiguously convey the users intent of numbering scope.
For example; when a user has a document with 100 list-items total, it should
be possible to state clearly that the first 12 items form one list and
another 7 items another list. Etc.
* Provide rules that allow implementations to read the structured (numbering)
data out of an ODF doc and show the same list item labels as all other
implementations.
The emphasis has to lie with the correct counter over the formatting of the
list item (so if the implementation does not support roman numbering, it can
show a 4 instead of IV).
* Modularity
Every list stands alone. Changing one list should not have any effect on other
lists. Removing one list should not have any effect on other list. Same
with adding a list into a document.
* A list style has to be able to be connected (by the implementation) to a
paragraph style. So I can have a H1 paragraph style which then auto-applies
the corresponding list style.
This implies that
a) different list styles can be used to make 1 list.
b) a list style only specifies the list-formatting for the level it
represents.
c) start values of each list-level are specified by the list-style applied
to the first list-item on that level
* To allow any supporting implementation to write out the (user) intended
lists using either text:list or numbered-paragraph formatting.
This implies
a) an implementation would be able to read either structure and then write
it out into the other structure without a numbering change.
b) an implementation internal data structure should have a representation in
either format, preserving user intent.
This does NOT imply;
1) both list structures have to have the same featureset.
2) each and every list imaginable has to be convertable to the other format
without loss.
3) an implementation internal data structure has to have a representation in
either format, with all the implementation-internal structures being
preserved without loss. In other words only a representation in -one- of the
formats is sufficient.
--
Thomas Zander