Nabble - w3.org - www-forms-editor

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

2009-12-15T10:46:52Z

John,

You're right. I think we should either add text content to element output/mediatype, or remove attribute output/mediatype/@... depending on what's been implemented.

Here's where you would use output/output/mediatype/@... by the way:

Leigh.

From: John Boyer [mailto:boyerj@...]
Sent: Tuesday, December 15, 2009 10:41 AM
To: Klotz, Leigh
Cc: public-forms@...; www-forms-editor@...
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@...

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@...>
To:	John Boyer/CanWest/IBM@IBMCA
Cc:	<public-forms@...>, <www-forms-editor@...>
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/@... 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 [boyerj@...]
Sent: Friday, December 11, 2009 9:18 AM
To: Klotz, Leigh
Cc: public-forms@...; www-forms-editor@...
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@...

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@...>
To:	<public-forms@...>, <www-forms-editor@...>
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,

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

2009-12-15T10:40:46Z

From:	"Klotz, Leigh" <Leigh.Klotz@...>
To:	John Boyer/CanWest/IBM@IBMCA
Cc:	<public-forms@...>, <www-forms-editor@...>
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@...]
Sent: Friday, December 11, 2009 9:18 AM
To: Klotz, Leigh
Cc: public-forms@...; www-forms-editor@...
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@...

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@...>
To:	<public-forms@...>, <www-forms-editor@...>
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)

Why does it not allow text content?

<output ref="foo"><mediatype>image/*</mediatype></output>

Leigh,

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

2009-12-11T09:42:17Z

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@...]
Sent: Friday, December 11, 2009 9:18 AM
To: Klotz, Leigh
Cc: public-forms@...; www-forms-editor@...
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@...

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@...>
To:	<public-forms@...>, <www-forms-editor@...>
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)

Why does it not allow text content?

<output ref="foo"><mediatype>image/*</mediatype></output>

Leigh,

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

2009-12-11T09:17:50Z

From:	"Klotz, Leigh" <Leigh.Klotz@...>
To:	<public-forms@...>, <www-forms-editor@...>
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)

Why does it not allow text content?

<output ref="foo"><mediatype>image/*</mediatype></output>

Leigh,

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

2009-12-11T08:59:51Z

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>

Leigh,

RE: Question to XForms authors and implementors: Multiple help, hint, alert elements per form control?

2009-12-11T08:33:13Z

[Moving this back to www-forms-editor as I mistakenly sent it to www-html-editor.]

Mark,

I see a larger issue here about the tension between implementor extensibility and authoring tools: a good schema for authoring would allow only that which is interoperable and recommended, while a good schema for implementors would require only minimal conformance and leave open the gates to innovation. It may be that we need two schemas, with one closer to minimal for implementors and one closer to strict and interoperable for authoring. (Implementations which provide extensions would be free to provide their own schemas with their own extensions, of course.)

You make a strong case for making an editorial change to XForms 1.1 to state that the first help/hint/alert is used, to clarify the existing text yet still allow room for expansion. Allowing multiples of label would a normative change, since the XForms 1.1 Recommendation does not allow multiple labels.

Leigh.

-----Original Message-----
From: Mark Birbeck [mailto:mark.birbeck@...]
Sent: Thursday, December 10, 2009 3:10 AM
To: Klotz, Leigh
Cc: www-html-editor@...; public-forms@...
Subject: Re: Question to XForms authors and implementors: Multiple help, hint, alert elements per form control?

Hi Leigh,

> We have proposed that a future erratum for XForms 1.1 note in the
> prose that multiple such elements per form control is at best not
> interoperable, and further that the schema definitions for which it
> can be conveniently disallowed be changed to do so.

Can I suggest that we don't be too restrictive? I would think that all we need to do is to work out what it takes to make things interoperable, were people to have multiple elements.

For example, we could simply say that authors can count on the first occurrence of one of these elements being processed, but after that, it will be application specific.

But doing this, we don't rule out any innovations that people might come up with.

> Are any implementors assigning special meaning to multiple help, hint, and alert elements?

We don't give it special meaning, but we don't disallow multiple elements, either.

When processors allow multiple elements to appear, then it creates some interesting possibilities. For example, CSS can be used to determine which of the elements gets displayed.

One illustration of this would be to have different labels and alerts depending on whether you are using a mobile or desktop device:

@media screen {
.handheld { display: none; }
}
@media handheld {
.screen { display: none; }
}

<xf:intput ref="name">
<xf:label class="handheld">Age</xf:label>
<xf:label class="screen">Age at next birthday</xf:label>

<xf:alert class="handheld">Age is required</xf:alert>
<xf:alert class="screen"
>You must enter your age. Come on...don't be shy.</xf:alert>
</xf:input>

You could also have the label determined by the state of the control:

.valid .reenter { display: none; }
.invalid .enter { display: none; }

<xf:intput ref="name">
<xf:label class="enter">Age at next birthday</xf:label>
<xf:label class="reenter">Please re-enter your age</xf:label>
</xf:input>

Slightly contrived examples, I realise. :)

But I'm simply trying to illustrate that there are areas to explore, and I don't think we gain anything by closing off this avenue of exploration by tightening up the schema.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@...

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR)

Question to XForms authors and implementors: Multiple help, hint, alert elements per form control?

2009-12-09T13:46:51Z

In XForms 1.1 [1] the inline content model and linked schemas allow a plurality of help, hint, and alert elements per form control.
For example, at the end of section [2]:

Content Set Minimal Content Model
UI Common (help|hint|alert|Action)*

The Recommendation text gives no indication what more than one would do.

I raised this issue today [3] in the Forms WG teleconference.

In the past, there was group discussion about the advisability of using multiple label elements distinguished by xml:lang attributes, and we decided to support only one label element. One argument was that I18N best practice calls for external references.

As far as I can tell, we had no discussion about multiple help, hint, or alert elements, and I believe their allowance is a result of insufficient precision in the inline content model.

We have proposed that a future erratum for XForms 1.1 note in the prose that multiple such elements per form control is at best not interoperable, and further that the schema definitions for which it can be conveniently disallowed be changed to do so.

Are any implementors assigning special meaning to multiple help, hint, and alert elements?

Leigh.

[1] http://www.w3.org/TR/2009/REC-xforms-20091020/
[2] http://www.w3.org/TR/2009/REC-xforms-20091020/#N74868
[3] http://lists.w3.org/Archives/Public/public-forms/2009Dec/att-0021/2009-12-09-v2.html#topic5

Attached: draft XSDs to validate XForms 1.1 instances hosted with XHTML 1.0.

2009-11-29T10:34:18Z

This is to share with you draft schemas to validate XForms applications.

I have mailed information about these schemas in recent days to both the W3C www-forms-editor and XSLTForms support mailing lists. I today discovered that "for greater convenience to the community in the future, the working group is taking action to define a working group note that specifically targets validation of XHTML with XForms". Therefore, please consider the attached an interim implementation until W3C issues the note, or possibly a contribution to that note..

Clearly an integration with the XHTML 2 modular schemas would be desirable but I had issues getting them to work with my tools, hence the 1.0 integration. Perhaps it would be helfpul to provide more than one profile?

The XForms 1.1 specification says ""A host language is expected to add attributes such as xml:lang as well as an attribute, named class, that holds a list of strings that can be matched by CSS class selectors." However, the XForms 1.1 schema does not include a class attribute. The intention seems to be that this attribute will be supplied via the host language integration. The approached used in the attached is to use the XForms schema verbatim--so it is not modified from a copyright perspective--and then redefines it so it incorporates the XHTML UI attributes.

Testing this script suggests there may be error(s) in the XForms 1.1 schema. The specification states "Core form controls always have labels directly associated with them as child elements— this is a key feature designed to enhance accessibility" [where core forms are listed at http://www.w3.org/TR/xforms11/#def-core-form-control]." However, it appears in some cases the schema requires labels for non core form controls where the spec does not, e.g., for case and group. Thus, a label is required for the case element per the schema; but there are examples of it in the spec without labels.

FYI, I also attached an ant script to validate XForms instances using the schemas.

--
Best,

Owen Newnan

cell 720 260-5753
home 303 697 1925
http://www.linkedin.com/in/OwenNewnan

<project default="validate-xsltforms-demos" name="xforms-validation" >


<property name="xsltforms.dir" location="." />
<property name="normative.dir" location="../standards" /> 
<property name="instances.dir" location="${xsltforms.dir}" />
<property name="instance" value="balance.xml" />
<property name="failonerror" value="false"/>

<target name="validate-xforms11" description="description">
<property name="instance.path" location="${instances.dir}/${instance}"/>

<echo>Validating ${instance.path}, failonerror = ${failonerror}. </echo>
<schemavalidate file="${instance.path}" warn="true" failonerror="${failonerror}">
<schema namespace="http://www.w3.org/1999/xhtml" file="${normative.dir}/xforms11-syntax-checker.xsd" />
<schema namespace="http://www.w3.org/2002/xforms" file="${normative.dir}/xforms11-with-xhtml-attributes.xsd" />
</schemavalidate>
</target>


<target name="validate-xsltforms-demos" description="Run validation on all demos.">

<antcall target="validate-xforms11"><param name="instance" value="balance.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="select-model.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="deep-copy.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="select-multi-col.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="first-field.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="bind.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="balance.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="hello.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="select1-drop.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="bookmarks.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="incremental.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="select1.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="button.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="input-width.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="spreadsheet.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="calculator.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="input.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="textarea.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="checkbox.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="secret.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="xf.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="select-from-file.xml"/></antcall>
<antcall target="validate-xforms11"><param name="instance" value="xpath.xml"/></antcall>
</target>

</project>

xforms11-syntax-checker.xsd (86K) Download Attachment
xforms11-with-xhtml-attributes.xsd (7K) Download Attachment
XForms-11-Schema.xsd (77K) Download Attachment

Need better usage of QName datatypes in XForms submissions

2009-11-23T16:41:07Z

The current XForms submission has an attribute called includenamespacesprefixes.

If you leave out this attribute, the submitted instance may receive numerous namespaces declarations from the containing document that are not declared on the root element of the instance itself.

If you add includenamespaceprefixes="", then the list of namespaces added to the root element is attenuated to those that are *visibly utilized*.

If you add a space separated list, e.g. includenamespaceprefixes="xforms xf xsd", then the namespaces added to those declared on the root element is the set of inherited namespaces that are *visibly utilized* plus those listed prefixes (if they do indeed exist as defined namespace prefixes).

The term *visibly utilized* was borrowed from exclusive canonicalization and refers to the namespace prefix being used in an element or attribute declaration.

A namespace prefix may also be used in an attribute value or other content. In this case, the prefix is not visibly utilized in the XML sense but is still needed in order for the submitted instance data to be reasonably interpreted. Indeed we added includenamespaceprefixes as an attempt to address this problem.

As we continue to write more mature products that interact with XForms-produced data, we're seeing some gaps here. An important case in point is the xsi:type attribute. It may contain a value like "xforms:date", but the prefix xforms is not visibly utilized, and so the submission data does not have the prefix if one has used includenamespaceprefixes="". This makes the data unusable by schema validating server-side modules.

In this case, we could make authors fix the problem by setting includenamespaceprefixes="xf xforms xsd" or some such, but making the form author fix the problem is a bandage solution that will become less tenable over time as we go further into componentization.

In the long run, it would be better to have our own definition of "visibly utilizing" an XML namespace that accommodates any QName datatype assignments. For example, xsi:type is defined as a QName in the XML schema schema. Generally, if the datatype of a node is QName, either from a type MIP or an available schema, then the XForms submission should look at the value of that node for additional namespace prefixes that may be in use.

We could even adopt a cheeky name for our new concept, such as "visibly using" the namespace, since after all you should use utilize when you can reasonably utilize use.

Cheers,
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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

Re: XForms in HTML Example will not validate

2009-11-18T10:04:55Z

Hi Robert,

The working group discussed the concern you raised today and has asked me to provide the following response:

XForms is designed to be a module that can be hosted by multiple host presentation languages (including multiple host languages being used simultaneously). XForms provides a rich array of XML data interaction and server connectivity capabilities to host languages. In an informative appendix (H), we provide an example using XHTML as the host language. Validation of XForms in combination with any host language requires a schema that combines XForms with that host language. In the immediate term, you would need to do that in order for you to validate your documents. However, for greater convenience to the community in the future, the working group is taking action to define a working group note that specifically targets validation of XHTML with XForms, and the working group is also working on getting this profile added to the W3C validator.

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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	"Robert C. Leif" <rleif@...>
To:	www-forms-editor@...
Date:	11/17/2009 03:02 AM
Subject:	XForms in HTML Example will not validate

Dear Editor,

I tried to make The example in Section H (http://www.w3.org/TR/2009/REC-xforms-20091020/#xforms-in-xhtml-00) and the downloadable example (attached) work with both XMLSpy and OxYgen. OxYgen employs a special declaration for XForms that includes Relax NG code. <?oxygen NVDLSchema="xhtml-xforms.nvdl"?>. This does not appear to be portable. In short, I would like to be able to use my CytometryML schemas with XForms including being able to have type checking active. Since the CytometryML schemas are proposed to be part of a standard, these schemas will be available without charge. I believe that the link to the XForms 1.1, W3C Recommendation 20 October 2009 should provide a complete working example. I have attached the XForm and schema that I copied from the Recommendation. I also tested the XForm with the <?xml version="1.0" encoding="UTF-8"?> declaration removed. It produced similar errors. Since html does not include XForms, the errors appear to be correct. I have tested some approaches that appear to interfere with html’s schema validating elements from other namespaces. However, they did not work either.

Thank you.

Robert C. Leif, Ph.D.

Vice President

Newport Instruments

5648 Toyon Road

San Diego, CA 92115

Tel. (619)582-0437

Email rleif@...

Web : www.newportinstruments.com

“ Complete XForms Examples (Non-Normative)

This section presents complete XForms examples. These and additional examples are maintained at http://www.w3.org/MarkUp/Forms/2002/Examples.

H.1 XForms in XHTML.”

XMLSpy error message:

File F:\XForms\XForms_XHTML\xforms_test.html is not valid.

Element 'html' has no declaration for an attribute named 'xmlns:xf'.

Error location: html / @xmlns:xf

Details

VC: Attribute Value Type: Element 'html' has no declaration for an attribute named 'xmlns:xf'.

OYgen 11 Editor error messages:

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Attribute "xmlns:my" must be declared for element type "html".

Start location: 2:7

End location: 2:53

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Attribute "xmlns:ev" must be declared for element type "html".

Start location: 2:54

End location: 2:98

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Attribute "xmlns:xsd" must be declared for element type "html".

Start location: 3:3

End location: 3:47

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Attribute "xmlns:xforms" must be declared for element type "html".

Start location: 3:48

End location: 3:92

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:model" must be declared.

Start location: 8:6

End location: 8:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:instance" must be declared.

Start location: 9:8

End location: 9:23

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "my:payment" must be declared.

Start location: 10:10

End location: 10:20

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "my:cc" must be declared.

Start location: 11:12

End location: 11:17

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:submission" must be declared.

Start location: 15:8

End location: 15:25

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:bind" must be declared.

Start location: 16:8

End location: 16:19

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:bind" must be declared.

Start location: 17:8

End location: 17:19

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Start location: 8:6

End location: 8:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:group" must be declared.

Start location: 21:6

End location: 21:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:trigger" must be declared.

Start location: 22:8

End location: 22:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 24:10

End location: 24:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "toggle" must be declared.

Start location: 25:10

End location: 25:16

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:trigger" must be declared.

Start location: 27:8

End location: 27:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 28:10

End location: 28:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "toggle" must be declared.

Start location: 29:10

End location: 29:16

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Unexpected element "xforms:group". The content of the parent element type must match "(p|h1|h2|h3|h4|h5|h6|div|ul|ol|dl|pre|hr|blockquote|address|fieldset|table|form|noscript|ins|del|script)*".

Start location: 21:6

End location: 21:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "switch" must be declared.

Start location: 34:6

End location: 34:12

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "case" must be declared.

Start location: 35:8

End location: 35:12

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "select1" must be declared.

Start location: 36:10

End location: 36:17

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 37:12

End location: 37:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "choices" must be declared.

Start location: 38:12

End location: 38:19

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "item" must be declared.

Start location: 39:14

End location: 39:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 40:16

End location: 40:28

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "value" must be declared.

Start location: 41:16

End location: 41:21

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "message" must be declared.

Start location: 43:16

End location: 43:23

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "item" must be declared.

Start location: 46:14

End location: 46:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 47:16

End location: 47:28

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "value" must be declared.

Start location: 48:16

End location: 48:21

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:input" must be declared.

Start location: 54:10

End location: 54:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 55:12

End location: 55:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "alert" must be declared.

Start location: 56:12

End location: 56:17

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:input" must be declared.

Start location: 60:10

End location: 60:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 62:12

End location: 62:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "submit" must be declared.

Start location: 65:10

End location: 65:16

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 66:12

End location: 66:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "case" must be declared.

Start location: 69:8

End location: 69:12

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "select1" must be declared.

Start location: 71:10

End location: 71:17

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 72:12

End location: 72:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "choices" must be declared.

Start location: 73:12

End location: 73:19

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "item" must be declared.

Start location: 74:14

End location: 74:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 75:16

End location: 75:28

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "value" must be declared.

Start location: 76:16

End location: 76:21

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "message" must be declared.

Start location: 77:16

End location: 77:23

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "item" must be declared.

Start location: 80:14

End location: 80:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 81:16

End location: 81:28

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "value" must be declared.

Start location: 82:16

End location: 82:21

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:input" must be declared.

Start location: 88:10

End location: 88:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 89:12

End location: 89:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "alert" must be declared.

Start location: 90:12

End location: 90:17

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:input" must be declared.

Start location: 94:10

End location: 94:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 95:12

End location: 95:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "submit" must be declared.

Start location: 99:10

End location: 99:16

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 100:12

End location: 100:24[attachment "xforms_test_xf.html" deleted by John Boyer/CanWest/IBM] [attachment "payment.xml" deleted by John Boyer/CanWest/IBM]

XForms in HTML Example will not validate

2009-11-16T21:45:30Z

Dear Editor,

Thank you.

Robert C. Leif, Ph.D.

Vice President

Newport Instruments

5648 Toyon Road

San Diego, CA 92115

Tel. (619)582-0437

Email rleif@...

Web : www.newportinstruments.com

“ Complete XForms Examples (Non-Normative)

This section presents complete XForms examples. These and additional examples are maintained at http://www.w3.org/MarkUp/Forms/2002/Examples.

H.1 XForms in XHTML.”

XMLSpy error message:

File F:\XForms\XForms_XHTML\xforms_test.html is not valid.

Element 'html' has no declaration for an attribute named 'xmlns:xf'.

Error location: html / @xmlns:xf

Details

VC: Attribute Value Type: Element 'html' has no declaration for an attribute named 'xmlns:xf'.

OYgen 11 Editor error messages:

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Attribute "xmlns:my" must be declared for element type "html".

Start location: 2:7

End location: 2:53

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Attribute "xmlns:ev" must be declared for element type "html".

Start location: 2:54

End location: 2:98

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Attribute "xmlns:xsd" must be declared for element type "html".

Start location: 3:3

End location: 3:47

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Attribute "xmlns:xforms" must be declared for element type "html".

Start location: 3:48

End location: 3:92

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:model" must be declared.

Start location: 8:6

End location: 8:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:instance" must be declared.

Start location: 9:8

End location: 9:23

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "my:payment" must be declared.

Start location: 10:10

End location: 10:20

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "my:cc" must be declared.

Start location: 11:12

End location: 11:17

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:submission" must be declared.

Start location: 15:8

End location: 15:25

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:bind" must be declared.

Start location: 16:8

End location: 16:19

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:bind" must be declared.

Start location: 17:8

End location: 17:19

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Start location: 8:6

End location: 8:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:group" must be declared.

Start location: 21:6

End location: 21:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:trigger" must be declared.

Start location: 22:8

End location: 22:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 24:10

End location: 24:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "toggle" must be declared.

Start location: 25:10

End location: 25:16

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:trigger" must be declared.

Start location: 27:8

End location: 27:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 28:10

End location: 28:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "toggle" must be declared.

Start location: 29:10

End location: 29:16

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Start location: 21:6

End location: 21:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "switch" must be declared.

Start location: 34:6

End location: 34:12

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "case" must be declared.

Start location: 35:8

End location: 35:12

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "select1" must be declared.

Start location: 36:10

End location: 36:17

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 37:12

End location: 37:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "choices" must be declared.

Start location: 38:12

End location: 38:19

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "item" must be declared.

Start location: 39:14

End location: 39:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 40:16

End location: 40:28

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "value" must be declared.

Start location: 41:16

End location: 41:21

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "message" must be declared.

Start location: 43:16

End location: 43:23

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "item" must be declared.

Start location: 46:14

End location: 46:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 47:16

End location: 47:28

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "value" must be declared.

Start location: 48:16

End location: 48:21

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:input" must be declared.

Start location: 54:10

End location: 54:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 55:12

End location: 55:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "alert" must be declared.

Start location: 56:12

End location: 56:17

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:input" must be declared.

Start location: 60:10

End location: 60:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 62:12

End location: 62:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "submit" must be declared.

Start location: 65:10

End location: 65:16

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 66:12

End location: 66:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "case" must be declared.

Start location: 69:8

End location: 69:12

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "select1" must be declared.

Start location: 71:10

End location: 71:17

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 72:12

End location: 72:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "choices" must be declared.

Start location: 73:12

End location: 73:19

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "item" must be declared.

Start location: 74:14

End location: 74:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 75:16

End location: 75:28

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "value" must be declared.

Start location: 76:16

End location: 76:21

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "message" must be declared.

Start location: 77:16

End location: 77:23

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "item" must be declared.

Start location: 80:14

End location: 80:18

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 81:16

End location: 81:28

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "value" must be declared.

Start location: 82:16

End location: 82:21

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:input" must be declared.

Start location: 88:10

End location: 88:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 89:12

End location: 89:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "alert" must be declared.

Start location: 90:12

End location: 90:17

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:input" must be declared.

Start location: 94:10

End location: 94:22

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 95:12

End location: 95:24

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "submit" must be declared.

Start location: 99:10

End location: 99:16

SystemID: F:\XForms\XForms_XHTML\xforms_test_xf.html

Engine name: Xerces

Severity: error

Description: Element type "xforms:label" must be declared.

Start location: 100:12

End location: 100:24

XForms en XHTML FranÃ§ais English Choisissez un mode de paiement Comptant cash Ne pas envoyer d'argent comptant par la poste. Carte bancaire credit NumÃ©ro de carte bancaire Saississez un numÃ©ro de carte bancaire en cours (sÃ©parez par un espace ou un trait d'union chaque groupe de chiffres) Date d'Ã©chÃ©ance Achetez Select Payment Method Cash cash Please do not mail cash. Credit credit Credit Card Number Please specify a valid credit card number (use spaces or hyphens between digit groups) Expiration Date Buy
<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:my="http://commerce.example.com/payment"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://commerce.example.com/payment"
elementFormDefault="qualified">

<xs:element name="payment">
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element ref="my:cc" />
<xs:element ref="my:exp" />
</xs:choice>
</xs:sequence>
<xs:attribute name="as" type="my:paymentAs" />
</xs:complexType>
</xs:element>
<xs:element name="cc" type="my:cc" />
<xs:element name="exp" type="xsd:gYearMonth" />

<xs:simpleType name="cc">
<xs:restriction base="xsd:string">
<xs:minLength value="12" />
<xs:maxLength value="19" />
<xs:pattern value="[0-9]+" />
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="paymentAs">
<xs:restriction base="xsd:string">
<xs:enumeration value="cash" />
<xs:enumeration value="credit" />
</xs:restriction>
</xs:simpleType>
</xs:schema>

Fw: Typo in XForms 1.1 Proposed Recommendation 18 August 2009

2009-10-21T16:18:57Z

Just in case this doesn't make it by another means...

----- Forwarded by John Boyer/CanWest/IBM on 10/21/2009 04:18 PM -----

From:	Jeff Schering/CanWest/IBM
To:	John Boyer/CanWest/IBM@IBMCA
Date:	10/21/2009 11:42 AM
Subject:	Fw: Typo in XForms 1.1 Proposed Recommendation 18 August 2009

Hi John

Last week I stumbled upon a typo in the XForms spec. I mentioned it to Vlad who told me to simply send an email to www-forms-editor@... and that you would end up seeing it. I did not know at the time that www-forms-editor is a mailing list. Apparently my message is still waiting to be moderated in because when I looked at the public archive this morning (http://lists.w3.org/Archives/Public/www-forms-editor/2009Oct/) it was still not there.

So I guess that means you do not know about it yet, and now the standard is an official recommendation! In any case, something for the backlog.

Cheers,
Jeff

Jeff Schering | Information Developer | IBM Canada Software Lab - Victoria Site | Tel: 250-294-7465 | schering@...

----- Forwarded by Jeff Schering/CanWest/IBM on 2009/10/21 11:35 -----

From:	Jeff Schering/CanWest/IBM
To:	www-forms-editor@...
Date:	2009/10/16 11:07
Subject:	Typo in XForms 1.1 Proposed Recommendation 18 August 2009

Hi

While perusing the XForms 1.1. spec, I stumbled upon a typo in the Glossary of Terms, here: http://www.w3.org/TR/xforms11/#def-valid-node. In the definition of valid node, "byt" should probably be "by".

Cheers,
Jeff

Jeff Schering | Information Developer | IBM Canada Software Lab - Victoria Site

Re: corrections in or related to XForms 1.1 submission module.

2009-10-20T16:48:33Z

Hi Vlad,

Thanks for sending these comments. Both have been remedied in the 1.1 recommendation, which was published today.

Thank you,
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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	Vlad Trakhtenberg/CanWest/IBM@IBMCA
To:	www-forms-editor@...
Cc:	public-forms@..., www-forms@...
Date:	10/12/2009 05:18 PM
Subject:	corrections in or related to XForms 1.1 submission module.

The XForms 1.1 spec says:

a).

6.1.4 The relevant Property

Description: indicates whether the model item is currently relevant. Instance data nodes with this property evaluating to false are not serialized for submission.

This seems to ignore the relevant="false" attribute of submission.

11.2 The xforms-submit Event

...
2. If the binding attributes of submission indicate an empty nodeset or a non-element node, then submission processing is stopped after dispatching event xforms-submit-error with context information containing an error-type of no-data. Otherwise, the binding attributes of submission indicate a node of instance data.

This seem to contradict the default value of the ref attribute of submission being "/".

Thanks,

Vlad Trakhtenberg,
IBM, Victoria Software Lab

Re: Semicolon better than ampersand as the default separator

2009-10-20T09:47:59Z

I agree with Mark, but he was quicker on the draw :-)

During the implementation phase, it was discovered that implementers by-and-large went with the current web default of ampersand when *constructing* URI parameters from instance data. We had to be responsive to that reality in order to exit CR.

However, to Mark's point, because the change concerns what separator is used to *construct* the URI parametners, the only occurrence of the separator character is in the separator attribute. So, changing the default to ampersand means you don't have to write an escaped ampersand into the XML markup of the submission in order to get ampersand separators. You can express it if you want, but you used to be forced to write an escaped ampersand separator on pretty much every submission, which is why the implementation community generally did not go this way.

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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	Mark Birbeck <mark.birbeck@...>
To:	Krzysztof Maczyński <1981km@...>
Cc:	www-forms@..., www-forms-editor@...
Date:	10/20/2009 07:21 AM
Subject:	Re: Semicolon better than ampersand as the default separator

Hi Krzysztof, You are right that the ampersand needs escaping, but that is exactly why it's a better choice as the default. With the change to XForms 1.1, authors only need to provide a value for @separator if the server they are addressing uses semi-colons. Regards, Mark -- Mark Birbeck, webBackplane mark.birbeck@...http://webBackplane.com/mark-birbeckwebBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR) 2009/10/19 Krzysztof Maczyński <1981km@...>: > Dear WG, > > Pardon the cross-posting, but I'm not sure to which list this should go. > > In XForms 1.1 PR the default of the separator attribute was changed to ampersand. Semicolon is a viable and fairly common alternative whose main advantage over ampersand is that it doesn't need escaping in XML and SGML. See also [1] and [2]. Worse even, authors often fail to escape it, which results in errors. I'd like to ask you to reconsider this change and I'd rather see it reverted. > > Best regards, > > Krzysztof Maczyński > Invited Expert, HTML WG > > [1]http://www.w3.org/DesignIssues/MatrixURIs> [2]http://xmltoday.org/content/dancing-naked-streets-madman-takes-html-5#comment-2240> (Not what you might expect having read that URI.) > >

Re: Semicolon better than ampersand as the default separator

2009-10-20T07:10:14Z

Hi Krzysztof,

You are right that the ampersand needs escaping, but that is exactly
why it's a better choice as the default. With the change to XForms
1.1, authors only need to provide a value for @separator if the server
they are addressing uses semi-colons.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@...

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

2009/10/19 Krzysztof Maczyński <1981km@...>:

> Dear WG,
>
> Pardon the cross-posting, but I'm not sure to which list this should go.
>
> In XForms 1.1 PR the default of the separator attribute was changed to ampersand. Semicolon is a viable and fairly common alternative whose main advantage over ampersand is that it doesn't need escaping in XML and SGML. See also [1] and [2]. Worse even, authors often fail to escape it, which results in errors. I'd like to ask you to reconsider this change and I'd rather see it reverted.
>
> Best regards,
>
> Krzysztof Maczyński
> Invited Expert, HTML WG
>
> [1] http://www.w3.org/DesignIssues/MatrixURIs
> [2] http://xmltoday.org/content/dancing-naked-streets-madman-takes-html-5#comment-2240
> (Not what you might expect having read that URI.)
>
>

Semicolon better than ampersand as the default separator

2009-10-19T14:05:30Z

Dear WG,

Pardon the cross-posting, but I'm not sure to which list this should go.

In XForms 1.1 PR the default of the separator attribute was changed to ampersand. Semicolon is a viable and fairly common alternative whose main advantage over ampersand is that it doesn't need escaping in XML and SGML. See also [1] and [2]. Worse even, authors often fail to escape it, which results in errors. I'd like to ask you to reconsider this change and I'd rather see it reverted.

Best regards,

Krzysztof Maczyński
Invited Expert, HTML WG

[1] http://www.w3.org/DesignIssues/MatrixURIs
[2] http://xmltoday.org/content/dancing-naked-streets-madman-takes-html-5#comment-2240
(Not what you might expect having read that URI.)

Typo in XForms 1.1 Proposed Recommendation 18 August 2009

2009-10-16T14:25:24Z

Hi

While perusing the XForms 1.1. spec, I stumbled upon a typo in the
Glossary of Terms, here: http://www.w3.org/TR/xforms11/#def-valid-node. In
the definition of valid node, "byt" should probably be "by".

Cheers,
Jeff

Jeff Schering | Information Developer | IBM Canada Software Lab - Victoria
Site

corrections in or related to XForms 1.1 submission module.

2009-10-12T17:15:00Z

The XForms 1.1 spec says:

a).

6.1.4 The relevant Property

Description: indicates whether the model item is currently relevant. Instance data nodes with this property evaluating to false are not serialized for submission.

This seems to ignore the relevant="false" attribute of submission.

11.2 The xforms-submit Event

Re: XForms 1.1 Namespace question?

2009-08-26T09:17:23Z

Hi Linus,

The namespace is the same.
XForms now has a version attribute that allows the processing of content to be distinguished if necessary.
Also, it's not a huge deal, but this forms editor list is intended for "formal" comments on the specification. So, please send discussion email and questions like this to www-forms instead because there is special process handling of all emails that come to this list.

Thank you,
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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	"Linus Kamb" <kamb@...>
To:	www-forms-editor@...
Date:	08/26/2009 08:52 AM
Subject:	XForms 1.1 Namespace question?

Just wondering if the namespace is to be changed for the XForms 1.1 specification. The document: http://www.w3.org/TR/2009/PR-xforms11-20090818/lists the namespace the same as the 1.0 version:http://www.w3.org/2002/xformshttp://www.w3.org/TR/2009/PR-xforms11-20090818/#structure-namespaceE.R. Harold reported that there was to be a new namespacehttp://www.w3.org/2004/xforms/With a trailing slash. (I thought trailing slashes were non-standard.) Just a comment. Thanks, Linus Kamb

XForms 1.1 Namespace question?

2009-08-26T08:24:18Z

Just wondering if the namespace is to be changed for the XForms 1.1
specification.

The document: http://www.w3.org/TR/2009/PR-xforms11-20090818/

lists the namespace the same as the 1.0 version:
http://www.w3.org/2002/xforms

http://www.w3.org/TR/2009/PR-xforms11-20090818/#structure-namespace

E.R. Harold reported that there was to be a new namespace
http://www.w3.org/2004/xforms/

With a trailing slash. (I thought trailing slashes were non-standard.)

Just a comment.

Thanks,

Linus Kamb

Typo in the PR

2009-08-21T07:18:13Z

Hi,

I noticed a small typo in the Consuming a SOAP 1.1 Request-Response Web Service example (http://www.w3.org/TR/2009/PR-xforms11-20090818/#SOAP) :

<xforms:model xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tns="http://webservice.example.exampleforms:instance id="data">

       <data xmlns="">

           <cit">

   <xforms:instance id="data">

       <data xmlns="">

           <city>Victoria</city>

           <country>Canada</country>

           <weather>Mostly sunny and cool. High 12C. Low 3C.</weather>

       </data>

   </xforms:instance>

Yours,

________________________________

Christian Rémillard
Webmestre
Direction des bibliothèques
Direction générale
2910 Édouard-Montpetit, bureau 112
Université de Montréal
C.P. 6128, succ. Centre-ville
Montréal (Québec) H3C 3J7

514 343-6111 #1977

Re: Fwd: [Moderator Action] XForms 1.1 spec error/typo

2009-08-11T07:18:09Z

Hi Alex,

Yes, we agree this is an error in the XForms 1.1 CR spec. It was noted and fixed a long time ago in the editor's draft [1], which we are currently working on transitioning to proposed recommendation.

[1] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html

There are very many fixes like this in [1], so it is better to use [1] for your reference at this point since the working group resolved to seek its transition in June.

Best regards,
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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	"Steven Pemberton" <Steven.Pemberton@...>
To:	"www-forms-editor@..." <www-forms-editor@...>
Date:	08/11/2009 07:07 AM
Subject:	Fwd: [Moderator Action] XForms 1.1 spec error/typo

------- Forwarded message ------- From: "Alex Sansom" <alex.sansom@...> To: www-forms-editor@... Cc: Subject: [Moderator Action] XForms 1.1 spec error/typo Date: Tue, 28 Jul 2009 11:02:15 +0200 Hi there, I was just looking at the latest Xforms 1.1 spec at <http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html> and I think there appears to be a couple of typos for both the xf:dayTimeDuration and xf:yearMonthDuration examples. They both start with '<xs:simpleType name="email">...</xs:simpleType>'. I'm pretty sure that the value for @name shouldn't be 'email'. <http://www.w3.org/TR/xforms11/#dt-dayTimeDuration> <http://www.w3.org/TR/xforms11/#dt-yearMonthDuration> Cheers, Alex

Fwd: [Moderator Action] XForms 1.1 spec error/typo

2009-08-11T07:05:59Z

------- Forwarded message -------
From: "Alex Sansom" <alex.sansom@...>
To: www-forms-editor@...
Cc:
Subject: [Moderator Action] XForms 1.1 spec error/typo
Date: Tue, 28 Jul 2009 11:02:15 +0200

Hi there,

I was just looking at the latest Xforms 1.1 spec at <
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html> and I think
there appears to be a couple of typos for both the xf:dayTimeDuration and
xf:yearMonthDuration examples. They both start with '<xs:simpleType
name="email">...</xs:simpleType>'. I'm pretty sure that the value for @name
shouldn't be 'email'.

<http://www.w3.org/TR/xforms11/#dt-dayTimeDuration>
<http://www.w3.org/TR/xforms11/#dt-yearMonthDuration>

Cheers,

Alex

Re: XForms 1.1 typo in the 4.5.4 The xforms-link-exception Event

2009-07-07T13:42:43Z

Thanks Vlad. This has been fixed in the latest editor's copy available from the working group home page.

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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	Vlad Trakhtenberg/CanWest/IBM@IBMCA
To:	www-forms-editor@...
Cc:	John Boyer/CanWest/IBM@IBMCA
Date:	07/07/2009 08:20 AM
Subject:	XForms 1.1 typo in the 4.5.4 The xforms-link-exception Event

Note in this section goes:

...XForms processors are not expected to product XForms user interface elements...

Vlad Trakhtenberg.
IBM, VIctoria Software Lab.

XForms 1.1 typo in the 4.5.4 The xforms-link-exception Event

2009-07-07T08:19:18Z

Note in this section goes:

...XForms processors are not expected to product XForms user interface elements...

Vlad Trakhtenberg.
IBM, VIctoria Software Lab.

Re: XForms 1.1 - repeat relevance & editorial tweaks.

2009-06-11T08:46:21Z

Thanks for your reply. I accept WG's argumentation and decision. Vlad Trakhtenberg.

John Boyer/CanWest/IBM@IBMCA
Sent by: www-forms-request@...

11/06/2009 08:02

To	Vlad Trakhtenberg/CanWest/IBM@IBMCA
cc	public-forms@..., www-forms@..., www-forms-editor@...
Subject	Re: XForms 1.1 - repeat relevance & editorial tweaks.

Hi Vlad,

Per our verbal discussion, the repeat itself does not get the enabled/disabled events because it does not have a single node binding.

However, each of the implicit groups representing rows of the table would receive these events because they do have a single node binding. And those events would bubble up to the repeat.

Regarding the typo in 8.1.1, it is fixed.

Regarding the link, it is intended to work when the document is officially published by the W3C, so it does not work when the document is placed at the working group editorial location.

Can you please reply to this email to indicate whether you are satisfied with the reply or whether you have any further concerns.

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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	Vlad Trakhtenberg/CanWest/IBM
To:	www-forms@..., www-forms-editor@...
Cc:	public-forms@..., John Boyer/CanWest/IBM@IBMCA
Date:	03/12/2009 05:13 PM
Subject:	XForms 1.1 - repeat relevance & editorial tweaks.

Dear WG,

Is there a compelling reason for the provision that xforms-disabled/enabled event cannot target repeat (4.4.1 -4.4.11) and repeat control cannot be relevant or non-relevant (8.1.1)?

Perhaps a repeat can become non-relevant'(relevant) and the xforms-disabled (enabled ) fire when it does not have any (has at least one) relevant repeat items (item)?

And a couple of minor issues:

1. Typo in 8.1.1: Second bullet:
...
Note:
Form controls that read or write simpleContent produce this exception whenever and as soon as they are bound to an element node that an element child node.

2. The very first link: (not terribly useful ;) http://www.w3.org/TR/2009/CR-xforms11-20090311/ does not work.

Regards,
Vlad Trakhtenberg.

Re: 11.2 The xforms-submit Event - concurrent submissions

2009-06-11T08:37:24Z

Hi Willi,

The working group accepted that a clarification to the spec was required to help ensure that it was clear that once a submission was in progress, further submit events *dispatched to that submission* resulted in xforms-submit-error.

The diff marks can be read here: http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#submit-evt-submit

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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

Re: XForms 1.1 - target of the xforms-delete event

2009-06-11T08:19:40Z

Thanks for your reply. Sounds fine to me. Vlad Trakhtenberg.

John Boyer/CanWest/IBM@IBMCA
Sent by: www-forms-editor-request@...

11/06/2009 08:11

To	Vlad Trakhtenberg/CanWest/IBM@IBMCA
cc	public-forms@..., www-forms@..., www-forms-editor@...
Subject	Re: XForms 1.1 - target of the xforms-delete event

Hi Vlad,

The working group decided that the behavior of delete action when the nodeset obtains nodes from multiple instances is undefined by the specification, leaving it open in XForms 1.1 for implementers to handle the case as they see fit.

Can you please let us know if this is acceptable to you for XForms 1.1?

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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	Vlad Trakhtenberg/CanWest/IBM
To:	public-forms@..., www-forms@..., www-forms-editor@...
Cc:	John Boyer/CanWest/IBM@IBMCA
Date:	05/27/2009 07:53 AM
Subject:	XForms 1.1 - target of the xforms-delete event

Dear WG,

According to the current XForms 1.1 spec the delete action can delete nodes from more than one XForms instance (if no delete location specified - as in 10.4 step 4 ). If so, which instance the corresponding xforms-delete event must target?

Regards,

Vlad Trakhtenberg,
IBM, Victoria Lab.

Re: Proposed clarification of what constitutes the provision of inline content of the xforms instance

2009-06-11T08:16:22Z

Thanks for your reply. I accept WG's argumentation and decision. Vlad Trakhtenberg.

"Steven Pemberton" <Steven.Pemberton@...>
Sent by: www-forms-editor-request@...

13/05/2009 08:28

To	Vlad Trakhtenberg/CanWest/IBM@IBMCA, www-forms-editor@..., public-forms@...
cc	John Boyer/CanWest/IBM@IBMCA
Subject	Re: Proposed clarification of what constitutes the provision of inline content of the xforms instance

Thanks for this comment. The Forms WG has discussed it, and we understand that it may be a bit of an inconvenience for the author, but we believe that the processing rules are easier this way, and the user will get a fairly clear error message. There is no loss of functionality with these rules, so we prefer to keep the rules as they are. Many thanks again. Steven Pemberton For the Forms WG On Mon, 09 Mar 2009 17:43:17 +0100, Vlad Trakhtenberg <vladt@...> wrote: > Hi all, > > I would like to propose to clarify XForms 1.1 Recommendation to say that > the inline content of the xforms instance element is considered to be > provided (in the context of section 3.3.2) if instance element has an > 'elemental' content i.e. has an element child. > Otherwise such benign markup as: > > <xforms:instance resource="http://example.org/testDataURI" > > </xforms:instance> > > or > > <xforms:instance resource="http://example.org/testDataURI" ></xforms:instance> > > will cause arguably unnecessary fatal processing error ( > xforms-link-exception) because the provided [non-empty?!] inline content > takes precedence over the resource attribute. > > Thanks, > Vlad Trakhtenberg.

Re: XForms 1.1 - target of the xforms-delete event

2009-06-11T08:11:21Z

From:	Vlad Trakhtenberg/CanWest/IBM
To:	public-forms@..., www-forms@..., www-forms-editor@...
Cc:	John Boyer/CanWest/IBM@IBMCA
Date:	05/27/2009 07:53 AM
Subject:	XForms 1.1 - target of the xforms-delete event

Re: XForms 1.1 - repeat relevance & editorial tweaks.

2009-06-11T08:02:03Z

From:	Vlad Trakhtenberg/CanWest/IBM
To:	www-forms@..., www-forms-editor@...
Cc:	public-forms@..., John Boyer/CanWest/IBM@IBMCA
Date:	03/12/2009 05:13 PM
Subject:	XForms 1.1 - repeat relevance & editorial tweaks.

Re: XForms 1.1 spec - section 11.1 - targetref - minor clarifications needed

2009-06-03T17:23:38Z

Hi Vlad,

The behaviors for the cases you mention are covered clearly in Section 11.10 on Replacing Data with the Submission Response (http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html#submit-data-replacement).

I believe the mixup is that you are reading the attribute summary only.

Best regards,
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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	Vlad Trakhtenberg/CanWest/IBM
To:	www-forms@..., www-forms-editor@...
Cc:	John Boyer/CanWest/IBM@IBMCA
Date:	06/03/2009 10:58 AM
Subject:	XForms 1.1 spec - section 11.1 - targetref - minor clarifications needed

Dear Editor/WG,

I think some clarifications are needed in description of the targetref attribute in section 11.

1. What should happen if the targetref resolves to an empty nodeset? (And specifically, with respect to instance attribute presence :).

2. What should happen if targetref points to a 'wrong' instance (given by the instance attribute)?

Ignoring instance attribute if targetref if present (and resolves to an non-empty nodeset?) or even its deprecation seems like a reasonable outcome.

Thanks,

Vlad Trakhtenberg,
IBM, Victoria Software Lab

XForms 1.1 spec - section 11.1 - targetref - minor clarifications needed

2009-06-03T10:58:59Z

Re: XForms 1.1 - target of the xforms-delete event

2009-06-02T15:56:19Z

John,

Got it.

This said, it would be disturbing to me that xforms:delete could
actually support deleting nodes from multiple instances simply because
XPath allows it, but that we would artificially prevent this from
working.

Either way, you would have to modify the spec to reflect either 1) the
NOP behavior or 2) the event dispatch.

Right now we say in "10.4 The delete Element":

"The delete action is successfully completed by dispatching the
xforms-delete event with appropriate context information."

It seems to me that it would be as easy to simply say:

"The delete action is successfully completed by dispatching the
xforms-delete event with appropriate context information to any
instance from which nodes were deleted."

And from the implementor's perspective, it doesn't make a big
difference either. The win is increased consistency.

-Erik

On Jun 2, 2009, at 11:31 AM, John Boyer wrote:

>
> Hi Erik,
>
> I think there's a misunderstanding. I wasn't saying that the delete
> *event* would not occur, but rather that the delete *action* itself
> should no-op if you try to delete nodes from multiple instances.
>
> I quite agree that the delete event would be useless if you couldn't
> count on it to let you know whenever nodes are deleted by an XForms
> supported mechanism (unfortunately, you're on your own with the DOM
> API).
>
> But I think form authors don't lose very much in practice if a
> delete action just simply doesn't work if you do a multiple instance
> delete. If you want to delete from multiple instances, just write
> multiple deletes. Multiple instance deletes are uncommon, and there
> is no effective change of the number of achievable applications by
> this limitation since the number of instances is static.
>
> Also, my consistency argument is about the actions, not the events.
> The XForms insert action can only insert into one instance, so it is
> reasonable to have an XForms delete action that can only delete from
> one instance. The events are just there to target the instance that
> was mutated by the action.
>
> This is the best limitation at this stage of XForms 1.1 since our
> only test on the xforms-delete event tests a deletion from a single
> instance. There is no test coverage for multiple instance deletion,
> so if we modify the spec to say it is possible, then we need a test
> and two conforming implementations. Given the above claim that
> there is no loss of power and no significant inconvenience in
> practice, it does not seem worth the trouble.
>
> Cheers,
> 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@...
>
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>
>
>
>
> From:
> Erik Bruchez <ebruchez@...>
> To:
> Forms WG <public-forms@...>
> Cc:
> xforms <www-forms@...>, www-forms-editor@...
> Date:
> 05/27/2009 11:02 AM
> Subject:
> Re: XForms 1.1 - target of the xforms-delete event
>
>
>
>
> > Another possible fix is to have xforms delete ignore nodes which are
> > not in the same instances as the first node, or to no-op entirely.
>
> This would make the xforms-delete event much less useful.
>
> > Insert can only insert nodes into one instance, so it is reasonable
> > to have consistency with delete. When delete was changed from one
> > node to many nodes, the most urgent requirement we had in mind to
> > satisfy was deletion of a set of children of a given node. This can
> > reasonably expand to nodes having a common ancestor, but crossing
> > DOMs just seems a little much, esp. without the analogous insert
> > ability.
>
> I don't buy the consistency argument here.
>
> We have to look at events from the perspective of form authors, not
> XForms implementors.
>
> If xforms-delete is an event you can listen to to figure out that
> nodes were inserted into a given instance, then it needs to be
> dispatched to an instance when nodes are removed from it. If
> xforms:delete is able to delete events from more than one instance,
> then it follows that xforms-delete must be dispatched to all instances
> from which nodes were removed.
>
> If we can't rely on an event to be accurately dispatched, then we
> should think about removing that event altogether.
>
> -Erik
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>
>
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Re: XForms 1.1 - typo

2009-06-02T11:42:42Z

Good catch. Thanks, I took care of it.

Cheers,
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@...

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

From:	Vlad Trakhtenberg/CanWest/IBM@IBMCA
To:	www-forms-editor@...
Date:	05/28/2009 09:18 AM
Subject:	XForms 1.1 - typo

Dear editor(s),

There's a typo (closing parenthesis is missing) in section 11.2 in the description of the processing of the targetref attribute:

"... a readonly parent or is not an element (if replace="instance". In this case, ... "

Vlad Trakhtenberg,
IBM, Victoria Software Lab.