W3C home > Mailing lists > Public > public-forms@w3.org > December 2009

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

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Tue, 15 Dec 2009 10:46:52 -0800
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF4097165ED@USA7061MS01.na.xerox.net>
To: "John Boyer" <boyerj@ca.ibm.com>
Cc: <public-forms@w3.org>, <www-forms-editor@w3.org>
John,
 
You're right.  I think we should either add text content to element output/mediatype, or remove attribute output/mediatype/@ <mailto:output/mediatype/@valueone>  depending on what's been implemented.
 
Here's where you would use output/mediatype/@value <mailto:output/mediatype/@value>  by the way:
 
<output ref="x"><mediatype value="concat('image/', ../@extension)" ></output>
 
Leigh.

________________________________

From: John Boyer [mailto:boyerj@ca.ibm.com] 
Sent: Tuesday, December 15, 2009 10:41 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?



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 <http://www.ibm.com/developerworks/blogs/page/JohnBoyer> 
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw <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 <mailto: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 <http://www.w3.org/TR/xforms11/#ui-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 <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 <http://www.ibm.com/developerworks/blogs/page/JohnBoyer> 
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw <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, 
Received on Tuesday, 15 December 2009 18:47:38 UTC

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