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

Hi Leigh,

Check out the bottom of your email, in the P.S.  You indicate that we 
added the value attribute to output/mediatype so that you could use a 
mediatype stored in instance data, e.g. from an upload control.

What I'm saying is look more closely at that and you will see that this is 
*not* why the value attribute is on output/mediatype.  In fact, this is 
why the single node binding (e.g. ref attribute) is on output/mediatype.

Look closer at the schema for upload.  You see that upload/mediatype has a 
single node binding but *not* a value.  It doesn't even make sense to have 
a value attribute on upload/mediatype because information has to travel 
from the upload control to the instance data, whereas the value attribute 
is only useful for one way communication from instance data to a form 
control.

The upload single node binding will put a mediatype into a single node of 
instance data, and the most natural and consistent way for an 
output/mediatype to consume that information would be to use its single 
node binding, not a value attribute. 

I quite agree with your table below that every other place where the value 
attribute exists, we also allow text content.  But we're talking about a 
schema change either way, and so my point is that if nobody can figure out 
how the value attribute got attached to output/mediatype, then the actual 
point of inconsistency looks to be the fact that the value attribute is 
attached to output/mediatype.  If you remove the value attribute, then you 
also remove the need for textual content in the output/mediatype element.

Then, given the above, the question might arise whether the value 
attribute plus the usual text content setting are needed in case one wants 
to set the mediatype to a literal string.  As you pointed out below, 
having the value attribute is usually associated with also having element 
text content available as a convenient alternate way of setting a literal. 
 This is the location in the argument where I put forward the 
output/@mediatype attribute as being available.  In other words, we 
shouldn't compel the addition of the value attribute in order to get at 
the text content method of setting a literal because we already have a way 
to set a literal.  So if a value attribute is needed, then why?  I don't 
see a reason.  At which point, I think that since we would need to modify 
the schema and produce an erratum anyway, why wouldn't we just remove the 
value attribute?

Thanks,
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:
John Boyer/CanWest/IBM@IBMCA
Cc:
<public-forms@w3.org>, <www-forms-editor@w3.org>
Date:
12/11/2009 09:45 AM
Subject:
RE: XForms 1.1: Why is output/mediatype text content not allowed?



Every other place where we have an element like this with a value 
attribute, text content is also allowed.  And most of them have attribute 
versions as well, so it's not because there's a output/@mediatype that we 
don't specify the behavior of output/mediatype/text().
 
Here's a comparison table:
 
submission/method   "The method to be used by the submission can be 
specified with either the value attribute or the string content of the 
method element."
submission/header/name "The header entry name may be given by the string 
content of the name element, or by the result of the value attribute."
submission/header/value "The header entry value may be given by the string 
content of the value element, or by the result of the value attribute. "
dispatch/name "The name element can provide the event name with either its 
string content or the value attribute. "
dispatch/targetid "The targetid element can provide an IDREF for the event 
target with either its string content or the value attribute. "
dispatch/target (deprecated but allowed with same content as 
dispatch/targetid)
dispatch/delay "The delay element can provide the delay with either its 
string content or the value attribute. "
setfocus/control " The control element can provide the desired element 
identifier with either its string content or the value attribute. "
toggle/case "The case element can provide the identity of a case with 
either its string content or the value attribute. "
(item|itemset)/value "3. the inline content of the value element (when 
neither the single node binding nor the value attribute are expressed)."
 
Only one is different:
output/mediatype   "If the binding attributes are not used, the value 
attribute must be used instead to specify the desired media type 
rendition."
 
We can use a pattern to express this in the schema (and in fact have to a 
first approximation of correctness) but for output/mediatype, it's 
incorrect because it's different from the others.
 
So I'd recommend that we make output/mediatype be the same as the others 
with regard to #PCDATA content and its processing.
 
Leigh.
BTW, the value attribute was added so it can use the mediatype specified 
in the instance, for example if you have a recently uploaded file from the 
upload control.

From: John Boyer [mailto:boyerj@ca.ibm.com] 
Sent: Friday, December 11, 2009 9:18 AM
To: Klotz, Leigh
Cc: public-forms@w3.org; www-forms-editor@w3.org
Subject: 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,