On Thu, 2008-09-25 at 14:27 +0200, Frank Schönheit - Sun Microsystems Germany wrote: > > I'm of the opinion that we _are_ following W3C standards, give or take > > an attribute name change -- W3C defines two attributes for this scenario > > (@id and @name), and the above solution has two attributes for this > > scenario (@form:name and @form:group-name), but I don't think this logic > > will go anywhere. > > I see your point here, but the problem with this interpretation is that > @form:name has - in ODF versions up to 1.1 - been defined with a > different semantics. In particular, it has not the character of an ID, > since it must not be unique at all. > > So, when we continue the line of your arguments, this would mean that > ODF 1.2 would re-defined the semantics of @form:name to really be a > unique identifier, which would pose problems with existing ODF > processors, in particular when writing documents.
Indeed, this problem hadn't occurred to me until Tuesday of this week - any existing ODF parsers aren't going to know about a group-name attribute, and thus will be relying on the name attribute for grouping semantics. Adding any form of group-name attribute cannot work in this context, not without extending the existing parsers to support the new attribute. > > I've noticed that ODF also has a @form:id attribute as well, but it > > seems that it would be difficult to "re-purpose" this attribute to store > > control names (as the value is apparently transient, for use with > > metadata). > > It's not for meta data, it's for connecting the form control models to > the shapes. I think there could be a way to reuse it, see below. > > > So I'm at a loss as to what to do next. The only other possible > > solution I've heard is to place the group-name attribute into the > > interop XML namespace, thus we'd have //form:radio/@form:name > > and //form:radio/@formx:group-name attributes, where `formx` would be > > the "urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:" > > XML namespace. > > Nice idea - do we already have something similar to this in ODF? I know that some parts in ooo-build make use of this, for a variety of interop scenarios. I am in fact pursuing this idea right now, in an effort to get it into the next ooo-build beta release for further testing. > Would this namespace be part of the ODF spec? No. > If not, to which degree would > such a document be a "valid" (in whatever weakened sense) ODF document? > Is there perhaps allowance in the ODF standard or a certain class of > "experimental" namespaces such as the one you suggested? It would not be valid in a strict sense, in that it would fail validation against the ODF schema. It would still be valid XML, as XML namespaces were designed for precisely this scenario (inserting "additional" data within an existing XML document). > Another idea might be to in fact introduce a property "ID" (or so), > which we require to be unique within the document. This ID could be > written as @form:id, we just need implement some additional logic. > > For instance, when importing controls in Excel documents, Excel's > "GroupName" would need to be mapped to "Name", and "Name" to "ID". > Sadly, for UNO dialog controls, this won't work, since their "Name" (in > opposite to form control's name) has always been used with an > ID-semantics. So, for those, "GroupName" would need to be imported as > (to-be-introduced) "GroupName", and "Name" as "Name". Which is bad, > since then the OOo API for form controls and dialog controls would be > different, but, well, ... Right, plus all the other implementation issues you mention. It wouldn't be an easy fix. So we should continue to pursue this as part of the ODF 3.0 or Interop committees so that we can "break" things (if necessary) for consistency in a controlled fashion. For the time being, though, I'll be implementing the alternate XML namespace approach. Thanks, - Jon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
