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: [OASIS Issue Tracker] Commented: (OFFICE-1603) Editor Note: Section17.244 fo:min-height

    [ http://tools.oasis-open.org/issues/browse/OFFICE-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11933#action_11933 ] 

Patrick Durusau commented on OFFICE-1603:

I am not going to comment on each "duplicate" attribute as there is a more general question that the TC needs to address for all such attributes.

My original take was to create a single chapter with all the attributes in it. Realize what I am about to say isn't my position but I am trying to give a fair rendition of it.

The original one chapter approach was objected to as not gathering in one place all the "formatting properties" for lack of a better term. That is to say that ODF has attributes that reflect values relevant to its structure, say chart:name, which is used to reference an axis in a chart, or, any of the smil:* attributes, which govern animation. It also has attributes which are relevant to the formatting of its content, such as many of the fo:* attributes. The thinking was that users interested in the formatting aspects would be better served with a separate chapter that contained the attributes of interest for that purpose. Hence, even though it resulted in duplicate reporting of some attributes, the fashioning of two chapters with attributes. 

As I said, that isn't my position but I am trying to fairly report the reasoning that was offered as the basis for the splitting of the attributes into two chapters. 

Having said that, however, note that the same argument can be made for gathering SMIL information, or any number of other parts of the standard together, which will result in more duplication and implied referencing as the earlier versions. Not to mention the always present demand for non-normative examples becomes, "...well, but X got to have examples, why not Y?" and that sort of thing. Not to mention all the wonderful information that is tied up in implementers notes.

So, what's a standard to do? 

I have heard the phrase "eating your own dogfood"  and suggest that we use XML and the new metadata capabilities of ODF 1.2 to deliver a standard that:

1) Has exactly one treatment of every element and attribute so that it is easier to consistently, reliably and hopefully more quickly evolve it to meet user requirements and,

2) Have the TC (and others) produce (non-normative) stylesheets that result in the incorporation of examples, annotations, implementer notes into a *rendering* of the standard and clearly delineated such additions as non-normative text.

Such stylesheets could even re-organize a rendering of the standard with the normative numbering maintained for reference to the standard.

The standard then becomes the basis for further documentation of both products and implementations of the standard, which should give us a lot more "eyes" on the text, never a bad thing. 

If anything this may hasten the appearance of ODF 1.2 since we won't have lengthy arguments about what, if any duplication is necessary, examples, etc. 

Can't ever tell, might even be the sort of demonstration that users could grok in terms of enhancing their document collections. ;-)

> Editor Note: Section 17.244 fo:min-height

> ------------------------------------------
>                 Key: OFFICE-1603
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-1603
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>    Affects Versions: ODF 1.2
>            Reporter: Robert Weir 
>            Assignee: Patrick Durusau
>             Fix For: ODF 1.2
> Transcribed from ODF_Revised_Editorial_Notes_27May2009.odt
> Original author: Patrick Durusau
> Section 17.244 fo:min-height
> Ed. Note Elsewhere we say that svg:height specifies a fixed or minimum height for a header or footer. Is there some reason to have two attributes for the same setting? 
> Oliver says:
> "Unfortunately, I have no answer to the question in this ed. note. 
> Somebody else?" 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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