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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oic message

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


Subject: 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:dennis.hamilton@acm.org]
Sent: Tue 2/24/2009 6:49 PM
To: Hanssens Bart; oic@lists.oasis-open.org
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:Bart.Hanssens@fedict.be]
Sent: Tuesday, February 24, 2009 06:41
To: oic@lists.oasis-open.org
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



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