OASIS Open Document Format for Office Applications (OpenDocument) TC

Greetings!

I am working on incorporating the rest of the Sun team and other 
comments into the next draft.

One item of particular concern is that we don't generally support the 
value "inherit" for any FO attributes.

Whether we should or not in some future release is not of present concern.

What is of concern is whether we should place all FO attributes in a 
separate section so we can make general statements about all FO 
attributes and not have to repeat where we don't support values, like 
inherit for any FO attribute.

There are other values that we don't support for particular values but 
those will be noted on those particular attributes.

I can't think of another value that we systematically don't support for 
FO attributes but I would like to avoid having to repeat that we don't 
support inherit time after time on attributes.

Realize this will change the section numbers from the current draft but 
I would rather do that now than after we have a public draft out for 
review.

My leaning is towards simply biting the bullet and doing the section for 
all FO attributes but I don't have to do it now while TC members are 
reviewing it. I can do that right before we send out a version for 
public review.

Thoughts/suggestions?

Hope everyone is having a great weekend!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Patrick Durusau wrote:

> Thoughts/suggestions?

I'm supporting idea of having separate section. But I would go further
and put original definitions from XSL-FO spec directly into ODF spec and
applied changes that ODF introduces to some XSL-FO properties. I think
that the current definition when ODF defines delta of XSL-FO spec (which
itself is delta off CSS2 spec) is not very good and doesn't help to
interoperability as XSL-FO defines properties on area tree where in ODF
there is no such formatting model defined at all.

(And aside from purely technical and spec writing reasons, such change
will make ODF 1.2 spec more acceptable for some national bodies during
ISO approval process.)

				Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

Hi,

On 11/08/08 20:56, Patrick Durusau wrote:
> Greetings!
> 
> I am working on incorporating the rest of the Sun team and other 
> comments into the next draft.
> 
> One item of particular concern is that we don't generally support the 
> value "inherit" for any FO attributes.

That is not specific to FO attributes. This also applies to those SVG 
attributes that are "properties" in SVG terminology. Most of them do 
also support a value "inherit" that ODF does not support.
> 
> Whether we should or not in some future release is not of present concern.
> 
> What is of concern is whether we should place all FO attributes in a 
> separate section so we can make general statements about all FO 
> attributes and not have to repeat where we don't support values, like 
> inherit for any FO attribute.

My suggestion would be to move all ODF formatting properties into 
separate section. We may then add a general statement about FO and SVG 
formatting properties, but the specification also gets clearer regarding 
what is a formatting property, and what is an attribute to an element.

Best regards

Michael


> 
> There are other values that we don't support for particular values but 
> those will be noted on those particular attributes.
> 
> I can't think of another value that we systematically don't support for 
> FO attributes but I would like to avoid having to repeat that we don't 
> support inherit time after time on attributes.
> 
> Realize this will change the section numbers from the current draft but 
> I would rather do that now than after we have a public draft out for 
> review.
> 
> My leaning is towards simply biting the bullet and doing the section for 
> all FO attributes but I don't have to do it now while TC members are 
> reviewing it. I can do that right before we send out a version for 
> public review.
> 
> Thoughts/suggestions?
> 
> Hope everyone is having a great weekend!
> 
> Patrick
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

2008/11/10 Michael Brauer - Sun Germany - ham02 - Hamburg

Dave Pawson wrote:

> Just how much do you want ODF to diverge from existing standards?

;-)

But actually I don't think that not having "inherit" in ODF has any real
impact. ODF document is usually very flat (sequence of paragraphs and
headings) compared to typical FO or SVG documents. So in ODF you usually
doesn't have element from which you can inherit something ;-)

			Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

Dave,

Dave Pawson wrote:
> 2008/11/10 Michael Brauer - Sun Germany - ham02 - Hamburg
> 

Michael,

I am checking all the responses I have gotten over the last couple of 
months to make sure I have incorporated or responded to all suggestions 
for the pre-Christmas draft.

The division into formatting properties versus others will not make it 
in that draft. :-(

However, so I can get a good run at it for next the draft after that, 
are there any "formatting" properties aside from those of SVG and FO? I 
have a sense there are but I don't think we have every enumerated them. 
Are any of the style properties "formatting" properties?|
|

I sense not because we do have some forms of inheritance for styles but 
not for SVG and FO properties.

Hope you are having a great weekend!

Patrick

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> Hi,
>
> On 11/08/08 20:56, Patrick Durusau wrote:
>> Greetings!
>>
>> I am working on incorporating the rest of the Sun team and other 
>> comments into the next draft.
>>
>> One item of particular concern is that we don't generally support the 
>> value "inherit" for any FO attributes.
>
> That is not specific to FO attributes. This also applies to those SVG 
> attributes that are "properties" in SVG terminology. Most of them do 
> also support a value "inherit" that ODF does not support.
>>
>> Whether we should or not in some future release is not of present 
>> concern.
>>
>> What is of concern is whether we should place all FO attributes in a 
>> separate section so we can make general statements about all FO 
>> attributes and not have to repeat where we don't support values, like 
>> inherit for any FO attribute.
>
> My suggestion would be to move all ODF formatting properties into 
> separate section. We may then add a general statement about FO and SVG 
> formatting properties, but the specification also gets clearer 
> regarding what is a formatting property, and what is an attribute to 
> an element.
>
> Best regards
>
> Michael
>
>
>>
>> There are other values that we don't support for particular values 
>> but those will be noted on those particular attributes.
>>
>> I can't think of another value that we systematically don't support 
>> for FO attributes but I would like to avoid having to repeat that we 
>> don't support inherit time after time on attributes.
>>
>> Realize this will change the section numbers from the current draft 
>> but I would rather do that now than after we have a public draft out 
>> for review.
>>
>> My leaning is towards simply biting the bullet and doing the section 
>> for all FO attributes but I don't have to do it now while TC members 
>> are reviewing it. I can do that right before we send out a version 
>> for public review.
>>
>> Thoughts/suggestions?
>>
>> Hope everyone is having a great weekend!
>>
>> Patrick
>>
>
>

-- 
Patrick Durusau 
patrick@durusau.net 
Chair, V1 - US TAG to JTC 1/SC 34 
Convener, JTC 1/SC 34/WG 3 (Topic Maps) 
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) 

Hi Patrick,

On 20.12.08 13:41, Patrick Durusau wrote:
> Michael,
> 
> I am checking all the responses I have gotten over the last couple of 
> months to make sure I have incorporated or responded to all suggestions 
> for the pre-Christmas draft.
> 
> The division into formatting properties versus others will not make it 
> in that draft. :-(
> 
> However, so I can get a good run at it for next the draft after that, 
> are there any "formatting" properties aside from those of SVG and FO? I 
> have a sense there are but I don't think we have every enumerated them. 
> Are any of the style properties "formatting" properties?|
> |

Yes, all attributes (and elements) that have one of the 

Michael,

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> Hi Patrick,
>
> On 20.12.08 13:41, Patrick Durusau wrote:
>> Michael,
>>
>> I am checking all the responses I have gotten over the last couple of 
>> months to make sure I have incorporated or responded to all 
>> suggestions for the pre-Christmas draft.
>>
>> The division into formatting properties versus others will not make 
>> it in that draft. :-(
>>
>> However, so I can get a good run at it for next the draft after that, 
>> are there any "formatting" properties aside from those of SVG and FO? 
>> I have a sense there are but I don't think we have every enumerated 
>> them. Are any of the style properties "formatting" properties?|
>> |
>
> Yes, all attributes (and elements) that have one of the 
> 

Hi Patrick,

On 22.12.08 14:29, Patrick Durusau wrote:

>>
> OK, but organizationally I understood your suggestion to be:
> 
> -- Gather all formatting attributes (SVG, FO, style:*) into a single 
> chapter (separate from current chapter 18)

Yes, this is what I suggest. However, there are formatting property 
attributes from other namespaces than the above, and there are a few 
attributes in the style namespace which are not formatting properties.

> 
>  From what you say above, are you suggesting that we need separate 
> treatment of all formatting elements and their children?

If the 

Michael,

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> Hi Patrick,
>
> On 22.12.08 14:29, Patrick Durusau wrote:
>
>>>
>> OK, but organizationally I understood your suggestion to be:
>>
>> -- Gather all formatting attributes (SVG, FO, style:*) into a single 
>> chapter (separate from current chapter 18)
>
> Yes, this is what I suggest. However, there are formatting property 
> attributes from other namespaces than the above, and there are a few 
> attributes in the style namespace which are not formatting properties.
>
OK, so all formatting properties, in the enumerated namespaces or not go 
into the formatting chapter. I don't remember the attributes in the 
style namespace that are not formatting properties but we can sort that 
out when deciding on the content of that chapter.
>>
>>  From what you say above, are you suggesting that we need separate 
>> treatment of all formatting elements and their children?
>
> If the 

Patrick,

On 22.12.08 15:18, Patrick Durusau wrote:
> Michael,
> 
> OK, so all formatting properties, in the enumerated namespaces or not go 
> into the formatting chapter. I don't remember the attributes in the 
> style namespace that are not formatting properties but we can sort that 
> out when deciding on the content of that chapter.

The attributes that the