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/@<output/mediatype/@valueone> depending
> on what's been implemented.
>
> Here's where you would use output/mediatype/@value<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
> 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*<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 <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,
>
>