Draft 17 Feedback

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi,

I received the following feedback to draft 17 from the OpenOffice.org 
developers:

A) Time data types
------------------
ISO8601 specifies in §5.3.1.3 that the delimiter for decimal fractions 
of a second can be either a comma (,) or a full stop (.), where a comma 
is the prefered sign. In contrast to this, the W3C schema specification 
for the 'dateTime' type says in §3.2.7.1 that the delimiter for 
fractions has to be a full stop (.). It also says in §3.2.7 that the 
'dataTime' type is "closely related" to ISO8601.

Our specification several times states that dateTime values have to 
conform to ISO8601 (for instance in section 6.2.2 Time fields). That 
means that a comma as well as a full stop would be allowed.  However, 
the data type that is used in the schema itself is the one of the W3C 
specification, and allows only a full stop.

The inconsistency in fact also applies to all data types containing a 
time values, like dataOrDateTime, time, or timeOrDateTime.

It seems to me that the should resolve this inconsistency, by either 
replacing the the references to ISO8601 with references to the W3C 
specification, or by redefining the dataTime data type to support a 
comma as well as a full stop.


B) cellRangeAddressList (section 8.3.1)
---------------------------------------
A "cellRangeAddressList" currently is specified as

<define name="cellRangeAddressList">
	<list>
		<oneOrMore>
			<ref name="cellRangeAddress"/>
		</oneOrMore>
	</list>
</define>

where "cellRangeAddress" is specified as

<define name="cellRangeAddress">
	<data type="string">
		<param 
name="pattern">($?([^\.']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+(:($?([^\.']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+)?</param>

	</data>
</define>

Unfortnately, using <list> in the definition of "cellRangeAddressList" 
does not work, because "cellRangeAddress" itself can contain space 
characters. Therfor, it seems that we have to replace the definition of 
"cellRangeAddress" with the regular expression:

(($?([^\.']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+(:($?([^\.']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+)?\ 
)*(($?([^\.']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+(:($?([^\.']+|'[^']+'))?\.$?[A-Z]+$?[0-9]+)?)


C) Schema for <tabke:highlighted-range> (section 8.4.4)
-------------------------------------------------------
The "table:cell-range-address" attribute should be optional as it was in 
the OOo DTD. The "<optional>" probably got lost when grouping the 
attributes into the two attribute lists 
"table-highlighted-range-attlist" and 
"table-highlighted-range-attlist-invalid".


D) Schema for <table:sort> (section 8.6.5)
------------------------------------------
There is an <optional> missing around the definition of the attribute 
table:bind-styles-to-content.


E) Schema for <table:sort-by> (section 8.6.6)
---------------------------------------------
There is a spelling error in the schema for some of this element's 
attributes. They are defined in part of "tabe-sort-attlist" rather than 
"table-sort-by-attlist"


F) Start and End markers (sections 15.13.6 and 15.13.7),
Opacity (section 15.14.14)
-------------------------------------------------------
The attributes draw:marker-start and draw:marker-end reference a marker 
style. When used within styles, it might be reasonable to switch of a 
marker that has been switched on in a parent style. There currently is 
no way to do that, because style names must not be empty. That's in fact 
the same issue we had with list styles. In the OOo schema, style names 
had the type CDATA, so an empty name was allowed here.

The same issue applies to the draw:opacity-name attribute.

I'm wondering whether we should allow style names to by empty if they 
are used to reference a style.


G) Images (section 9.3.2)
-------------------------
Within presentations, images like any other drawing objects, may contain 
text content. The only exception are OLE objects and (obviously) text 
boxes. In the current schema, images may not contain text content, and 
actually this was already the case for the OOo DTD, so this would be 
either the removal of an inconsisency or a new feature.


Best regards

Michael