RE: XForms 1.1: Why is output/mediatype text content not allowed? from Klotz, Leigh on 2009-12-15 (public-forms@w3.org from December 2009)

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Tue, 15 Dec 2009 14:26:06 -0800
To: "Erik Bruchez" <ebruchez@orbeon.com>, <public-forms@w3.org>
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF409716840@USA7061MS01.na.xerox.net>
Erik,
The schema can be changed easily and consistency in the @value and value nodes would be good (and is my goal in the schema), but John and I are at the mment looking at the normative text, which doesn't allow output/mediatype/text().  Either way, we'd have to chamnge the spec text to allow output/mediatype/text( )or disallow output/mediatype/@value.  Thanks for agreeing that keeping @value is useful.
 
Leigh.
 

________________________________

From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of Erik Bruchez
Sent: Tuesday, December 15, 2009 2:22 PM
To: public-forms@w3.org
Subject: Re: XForms 1.1: Why is output/mediatype text content not allowed?


Leigh is correct: removing @value would be a shame, because @value doesn't do the same thing as @ref. 

I don't think we should be too constrained by the schema anyway: the schema is just a minimal step towards what's allowed or not.

It would be fine to me to say:

* <mediatype> element supports @ref, @bind, @value and text context
* if <mediatype> is used in circumstances where it must *write* or *read/write*, then only @bind and @ref are allowed
* if <mediatype> is used in circumstances where it must *read*, then all attributes are allowed

(If we go this way this should be applied consistently, not only to <mediatype>.)

-Erik


On Tue, Dec 15, 2009 at 1:46 PM, Klotz, Leigh <Leigh.Klotz@xerox.com> wrote:


	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 22:26:51 UTC