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: Requirements regarding ODF lists from


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

PGP signature



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