Re: XForms 1.1: Why is output/mediatype text content not allowed?

It started as being the same mediatype element as is used with the upload 
element, and then the value attribute was added for some reason that I 
don't know/recall (so, I hope it wasn't me who asked for it).

The upload mediatype element cannot use a value attribute because the 
element is only needed when the author wants to store in data the 
mediatype of the uploaded content.  I can't think of a technical reason 
not to remove the value attribute from output's mediatype element for 
consistency. Note that the output element has a mediatype attribute that 
would provide exactly the same encoding as would a mediatype element's 
text content (were it allowed by the schema), and it would be easier to 
use for encoding a static string than would the child element.

John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
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
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
"Klotz, Leigh" <Leigh.Klotz@XEROX.COM>
To:
<public-forms@w3.org>, <www-forms-editor@w3.org>
Date:
12/11/2009 09:03 AM
Subject:
XForms 1.1: Why is output/mediatype text content not allowed?



 Here's the spec text for output/mediatype element:
8.1.5.1 The mediatype Element (for output)
Binding attributes on author-optional element mediatype specify the 
location in the instance of the string that indicates the desired media 
type rendition for the parent output. If the binding attributes are not 
used, the value attribute must be used instead to specify the desired 
media type rendition.
Why does it not allow  text content?
  <output ref="foo"><mediatype>image/*</mediatype></output>
It's hard justify this restriction because it's different from other SNB 
elements with value, which  do  support  inline content.  Removing this 
restriction would allow for more re-use of types in the schemas, and 
better author familiarity with our rules. 
Leigh,