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


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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

Subject: Re: [office-comment] Eliminate "text-numbered-paragraph",and are that many different types really needed?


David A. Wheeler wrote:
> Section 2.3.1 discusses text documents, including the
> text document content model, and defines a few
> text-content types.  Obviously text-p is there for normal
> text. I guess I can see the need to
> separate the text-h (header) material to easily
> identify headers (for outliners etc.). I can
> _sort_ of see the use of text-list, thought perhaps
> that should strictly be a style issue.
> But I see no value in making text-numbered-paragraph
> its very own type.  That should be a style setting.
> Creating specialized types like this is asking for
> trouble, I think.  The text describing them in 4.3.4
> simply encourages this kind of thinking even further.

In many situations, numbered paragraphs constitute a list. In this case, 
the list is part of the document structure, and it seems to be 
reasonable to represent this by an element of its own in the content of 
the document and not in the styles only. HTML for instance is doing the 

During its discussion, the TC identified also the need for having 
numbered paragraph that are simply numbered, but don't constitute a 
list. For consistency with the definition of lists, it seems to be 
reasomable to represent numbered paragraphs by an content element as 
well an not only by a style property.

> Also, there seem to be a lot of specialized types listed
> here (text-user-index vs. text-object-index, for example).
> Is there really a need for all of these to have their
> own specialized types?  It doesn't seem very orthogonal.

While all the index elements are similar, they actually are not the 
same. All of them require slightly different attributes and child 
elements. Obviously, one could combine them into a single element having 
all attributes/child-elements, but this would weaken the schema itself, 
because less errors could be found by validating a document against its 

The TC in fact checked whether the various index mark elements, that are 
less complex as the index elements themselves, could be combined into a 
single one, but came to the conclusion that they are to different to do so.

Best regards

Michael Brauer

OASIS Open Office TC chair

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