RE: [oic] form interoperability

Title: RE: [oic] form interoperability

Dennis,

I'm afraid this (form) one might be quite a puzzle to solve...

I've found at least two other cases, but less troublesome

* 9.5 Custom shape / Draw Engine

The optional draw:engine attribute specifies the name of a

rendering engine that can be used to render the custom shape.

The attribute's value is a namespaced token (....)

If the draw:engine attribute is omitted, the office

application's default enhanced custom shape rendering engine

will be used (...)

-> if implementations are really doing just that, it shouldn't

be a problem for interoperability (although once again I don't

get why this is part of the content.xml)

* 10.2 Chart content / Class

The chart:class attribute specifies the chart type. The chart

type is represented by a namespaced token (...)

This specification defines a number of chart types in the chart

namespace (urn:oasis:names:tc:opendocument:xmlns:chart:1.0).

Additional chart types may be supported by using a different

namespace.

-> could be a problem for interoperability, perhaps it should be

explicitly specified that implementations must (re)use existing

chart types when available (as far as I'm concerned, the ones

that are part of ODF should be the _only_ ones to be used, if we

need more types, they should be part of ODF-Next...)

Best regards,

Bart

-----Original Message-----

From: Dennis E. Hamilton [mailto:]

Sent: Tue 2/24/2009 6:49 PM

To: Hanssens Bart; 

Subject: RE: [oic] form interoperability

Wonderful,

You've found another place where QName prefixes are used in attributes as a

form of extension.  (The famous one is table:formula of course, the elephant

under the carpet is scripts.)   Good, there's a conversation over on ODF 1.2

about figuring out what to do about any or all of these under a desire for a

"pure" conformance level.

 - Dennis

-----Original Message-----

From: Hanssens Bart [mailto:]

Sent: Tuesday, February 24, 2009 06:41

To: 

Subject: [oic] form interoperability

Mm, I'm trying to come up with a test document for forms, but I stumbled

upon this:

* ODF 1.1, 11.4.2 Control Implementation

A control may be given a control type attribute, which determines which

concrete rendition or implementation the user agent should instantiate.

For easy extensibility, the value of this attribute is a namespaced

token,

i.e., it is token using a namespace prefix, much like attributes in XML.

So the form:control-implementation would be like a hint, not required to

get the field rendered in a reassuring dull way, right ?

If so, shouldn't this be in the application-specific settings.xml

instead of being sprinkled out over the form ? In settings.xml, you

could then define something like "render all textarea's using a really

spiffy control"

Best regards,

Bart