W3C home > Mailing lists > Public > public-forms@w3.org > October 2007

Re: Why is it hard to remove unwanted top-level elements from XForms schema?

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Thu, 25 Oct 2007 14:03:03 -0700
Message-ID: <47210487.3000300@orbeon.com>
To: "Forms WG (new)" <public-forms@w3.org>

It would be nice if an element with a given name was behaving 
consistently, independently from its location. In general, I think 
following this principle is good practice.

But here since in one location we are just extending the behavior, I 
think it is an ok approach.

-Erik

John Boyer wrote:
> 
> So, I'm just going through the schema, and I will give you a separate 
> report about that shortly.
> 
> However, one of our last call comments from Steven asked to have the 
> value attribute available on the mediatype child element of output.
> 
> This causes that mediatype element to not be the same type as the one 
> used in the upload control, which was known at the time we agreed to 
> Steven's request.  If you are *not* using output and upload together, 
> then having the value attribute on output's mediatype actually is 
> convenient.
> 
> Of course, it opens up the problem of what to do in the schema.  As a 
> top level element, we used to have mediatype defined as follows:
> 
>         <xsd:element name="mediatype">
>                 <xsd:complexType>
>                         <xsd:attributeGroup 
> ref="xforms:Common.Attributes"/>
>                         <xsd:attributeGroup 
> ref="xforms:Single.Node.Binding.Attributes"/>
>                 </xsd:complexType>
>         </xsd:element>
> 
> And then the upload and output elements had definitions that included 
> this element, like this:
> 
>         <xsd:element ref="xforms:mediatype" minOccurs="0"/>
> 
> Now that the value attribute must be added for output (and it doesn't 
> make sense in upload, by the way), we would have the need for two 
> top-level element both named mediatype and with different schema.  As 
> far as I know, you can't do that, so I solved the problem by creating 
> complex type definitions for the two different mediatype elements 
> needed, like this:
> 
>         <xsd:complexType name="mediatype">
>                 <xsd:attributeGroup ref="xforms:Common.Attributes"/>
>                 <xsd:attributeGroup 
> ref="xforms:Single.Node.Binding.Attributes"/>
>         </xsd:complexType>
>         <xsd:complexType name="mediatypeWithValue">
>                 <xsd:complexContent>
>                         <xsd:extension base="xforms:mediatype">
>                                 <xsd:attribute name="value" 
> type="xforms:XPathExpression" use="optional"/>
>                         </xsd:extension>
>                 </xsd:complexContent>
>         </xsd:complexType>
> 
> Then upload gets the following:
> 
>         <xsd:element name="mediatype" type="xforms:mediatype" 
> minOccurs="0"/>
> 
> And output gets the following:
> 
>         <xsd:element name="mediatype" type="xforms:mediatypeWithValue" 
> minOccurs="0"/>
> 
> First question: Can anyone see a problem with the approach I used?
> 
> Second question:  If not, then why is it more than an hour or so of work 
> to remove unwanted elements from the top level?
> 
> Granted it's not critical path to CR, but if it's this easy then when we 
> get done with the LC issues, we may as well just get this done.
> 
> Cheers,
> John M. Boyer, Ph.D.
> STSM: Lotus Forms Architect and Researcher
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com  
> 
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> 


-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Thursday, 25 October 2007 21:03:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:45 UTC