Hi Leigh and Martin,
The resource element in your example, Leigh, needs to use a value
attribute, not a ref, and the resource element has no replace attribute
(replace all is the default of submission, though, so you can probably
just remove it).
Regarding the test you are trying to perform, Leigh, it should be noted
that whether particular implementation will resolve IRIs like the one you
provided is different from determining whether an XML Schema 1.0 engine
will validate the XForm. Most run-time processors do not, for the sake of
expediency, validate the document. They also delegate URI resolution to
existing tools, so if those tools are more advanced in their support of
IRIs, then an implementation would work even if it is not required to do
so.
For this reason, Leigh, could I ask you to attach the actual file
i18n-resource.xml rather than pasting its content so we can be sure that
nobody's mail programs are doing any "favors" regarding character
encoding?
The reason I ask is that, based on what I see, I do not understand how the
the IRI you posted manages to conform to the anyURI definition given in
XML Schema 1.0 at [1].
[1]
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#anyURI
Martin, an explanation of why it conforms would be helpful because the
emails you linked did not seem to explain at all how anyURI is wider than
IRI. Such explanation of conformance should say something like "the
result of processing by section 5.4 of XLink is XYZ, the result of which
is a sequence of characters that match the uric BNF rule in RFC 2396 (as
amended by RFC 2732 with brackets and such)".
For what it's worth, it does *seem like* we might be in the good here
because I *think* the locator attribute processing (from Section 5.4 of
XLink [2]) converts a whole mess of characters disallowed by RFC 2396 as
the first step of the schema validation. In other words, I think the
specs are saying that the lexical space of xsd:anyURI contains lots of the
so-called disallowed characters because schema validation escapes them and
then checks the resulting string for compliance with RFCs 2396 and 2732.
[2] http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators
I am asking you to confirm whether this understanding is accurate. If so,
then it implies that XForms implementers will have to check whether their
URI resolvers already do the XLink escaping before feeding the string to
their URI resolvers. It depends on the implementation of course, but I
think the need to do this is buried in enough other specs that it is
noteworthy within the XForms spec.
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
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
"Klotz, Leigh" <Leigh.Klotz@xerox.com>
Sent by: www-forms-editor-request@w3.org
09/27/2007 09:24 AM
To
"Martin Duerst" <duerst@it.aoyama.ac.jp>, John Boyer/CanWest/IBM@IBMCA
cc
"Felix Sasaki" <fsasaki@w3.org>, "Forms WG (new)" <public-forms@w3.org>,
<public-forms-request@w3.org>, <public-i18n-core@w3.org>,
<www-forms-editor@w3.org>
Subject
RE: [XForms 1.1] i18n comment: IRIs for external schema locations
possible? (PR#8)
Martin,
I have a request for you to help me.
It might be useful to test an XForms user agent with IRIs in the
submission resource, where the resource is specified indirectly through
the instance data, using the new XForms 1.1 feature, like this:
<?xml version="1.0"?>
<html xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="
http://www.w3.org/1999/xhtml" xmlns:xf="http://www.w3.org/2002/xforms">
<head>
<title>I18N Resource Test</title>
<xf:model>
<xf:instance src="i18n-resource.xml />
<xf:submission id="test" method="get" serialize="false">
<xf:resource ref="resource" replace="all"/>
</xf:submission>
<xf:bind nodeset="resource" type="xsd:anyURI" />
</xf:model>
<style type="text/css">
@namespace xf url('http://www.w3.org/2002/xforms');
</style>
</head>
<body>
<h1>I18N Resource Test</h1>
<xf:submit submission="test">
<xf:label>Test</xf:label>
</xf:submit>
</body>
</html>
We can then put an IRI in i18n-resource.xml and test it in the submission
above:
<?xml version="1.0"?>
<data>
<resource>http://xformstest.org/2007/09/i18n-resource/i18n-リソース・テ
スト.html
</data>
The test then verifies that the HTTP GET resulting from the submission
test gets the right resource from the xformstest.org server.
But in order to do so I need to know that I've got xformstest.org
configured correctly.
I have placed a sample file at the location specified and would appreciate
it if you could check http://xformstest.org/2007/09/i18n-resource/i18n-リ
ソース・テスト.html and verify that it is appropriate for this test of IRI
handling.
Thank you,
Leigh.
-----Original Message-----
From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On
Behalf Of Martin Duerst
Sent: Thursday, September 27, 2007 12:49 AM
To: John Boyer
Cc: Felix Sasaki; Forms WG (new); public-forms-request@w3.org;
public-i18n-core@w3.org; www-forms-editor@w3.org
Subject: Re: [XForms 1.1] i18n comment: IRIs for external schema locations
possible? (PR#8)
At 15:19 07/09/27, John Boyer wrote:
>Hi Martin,
>
>We could use a few IRI samples with various non-ASCII characters in them,
esp. if they were already expressed with entity encodings and other such
measures needed to allow us to place them directly into an attribute value
or the text content of an element.
It's not really a problem to place the actual characters into
these attribute values. But you don't have to worry about that,
my program/framework does this automatically. What's more difficult
(but what my framework also handles) is to set up the
files with IRI addresses correctly on the server. There, you can't
just use entities or numeric character references.
By the way, my framework also automatically creates tests using
numeric character references, just so that they also get tested.
I'm not currently using any real entities (e.g. &uuml;), but I'm
thinking about adding them for where it makes sense (HTML, not much
else).
>We do not currently have tests that I know of along the lines you are
asking about.
>XForms, the technical report, delegates the whole issue of xsd:anyURI
correctness to [1] (as previously mentioned in the email to Felix), so our
existing tests would sample from the lexical space defined in [1].
I'm not really asking for tests exploring the lexical space.
What I'm asing is for tests that use plain old URIs in slots
that are defined as xsd:anyURI, to test whether the basic
linking functionality of these slots is implemented.
>We would be especially interested to know if there exist any IRIs that do
not comply to the lexical space definition appearing in [1].
Recent discussion (see the thread starting at
http://lists.w3.org/Archives/Public/public-iri/2007Jul/0025.html
and also
http://lists.w3.org/Archives/Public/public-i18n-core/2007JulSep/0063.html)
has shown that the contrary is true, that the anyURI definition
has a wider space than the IRI definition. The difference is
mostly due to historical accident, and the characters in the
difference set are mostly marginal, useless, or dangerous,
with some exceptions.
Regards, Martin.
>[1] <
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#anyURI>
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#anyURI
>
>Thank you,
>John M. Boyer, Ph.D.
>STSM: Lotus Forms Architect and Researcher
>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
>
>
>
>
>Martin Duerst <duerst@it.aoyama.ac.jp>
>Sent by: public-forms-request@w3.org
>
>09/26/2007 08:15 PM
>To
>John Boyer/CanWest/IBM@IBMCA, Felix Sasaki <fsasaki@w3.org>
>cc
>"Forms WG (new)" <public-forms@w3.org>, public-i18n-core@w3.org,
www-forms-editor@w3.org
>Subject
>Re: [XForms 1.1] i18n comment: IRIs for external schema locations
possible? (PR#8)
>
>
>
>
>
>Hello John,
>
>Do you/the XForms WG have any test cases that include dereferencing
>any of the anyURI-type fields mentioned below? I have a framework
>that can easily generate tests using various non-ASCII characters,
>so that we could test various implementations regarding whether
>they support anyURIs (which are in essence IRIs).
>
>Regards, Martin.
>
>At 01:55 07/09/27, John Boyer wrote:
>
>>Hi Felix,
>>
>>The Forms WG authorized the following response:
>>
>>We now believe we understand what you have asked. We agree that the
XForms 1.1 last call specification contained language about the host
language supplying the src attribute. We also agree that the datatype of
the resource attribute was missing from the overview table in [1] (the
overview tables are where we normatively state the datatypes of
attributes, such as those of the instance element in this case).
>>
>>[1] <<
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-abstract
>
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-abstract
>
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-abstract
>>
>>Both of these problems have been corrected in the normative text of
XForms 1.1, which can be seen in the editor's draft at [1]. The src
attribute is no longer regarded as being provided by the host language for
the instance element [2], and both src and resource are defined to be of
type xsd:anyURI [1].
>>
>>[2] <<
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-model-instance
>
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-model-instance
>
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-model-instance
>>
>>Also note that XForms also uses xsd:anyURI (normatively) in a few other
places, such as the action and resource attributes of submission and load
elements, the schema attribute of model, and the resource-uri event
context info properties of a number of events. However, in all these
other cases, the datatype was already identified (normatively) to be
xsd:anyURI.
>>
>>In all of these cases, xsd:anyURI is interpreted as meaning the anyURI
datatype defined in XML Schema 1.0 Part 2 Second Edition [3]
>>
>>[3] <<
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#intro-conventions
>
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#intro-conventions
>
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#intro-conventions
>>
>>Finally, note that [4] does still mention that a host language may
decide to include a linking attribute on our elements, but we do not
mention the content model for such attributes as those are under the host
language control and not XForms.
>>
>>[4] <<
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-attrs-link
>
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-attrs-link
>
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-attrs-link
>>
>>Due to the above, we believe that the concern you expressed about
normatively referencing xsd:anyURI has now been satisfied for all
attributes in the latest XForms 1.1 working draft.
>>
>>John M. Boyer, Ph.D.
>>STSM: Lotus Forms Architect and Researcher
>>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>
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>>
>>
>>
>>
>>Felix Sasaki <fsasaki@w3.org>
>>
>>09/26/2007 12:36 AM
>>To
>>John Boyer/CanWest/IBM@IBMCA
>>cc
>>public-i18n-core@w3.org, www-forms-editor@w3.org, "Forms WG (new)"
<public-forms@w3.org>
>>Subject
>>Re: [XForms 1.1] i18n comment: IRIs for external schema locations
possible? (PR#8)
>>
>>
>>
>>
>>Hi John again,
>>
>>we discussed the issue at our call yesterday, see
>><<http://www.w3.org/2007/09/25-core-minutes#item09>
http://www.w3.org/2007/09/25-core-minutes#item09>
http://www.w3.org/2007/09/25-core-minutes#item09 .
>>
>>We would like to make you aware of two aspects of the topic:
>>
>>First, IRIs are actually a subset of what XLink does (which is
>>referenced by XML Schema 1.0).
>>
>>Second: our real comment on your specification is not "reference IRI
>>instead of anyURI" ,but rather: it is not clear to us whether IRI or XML
>>Schema xsd:anyURI support is required normatively or depends on the host
>>language(s) of XForms 1..
>>
>>We would prefer that you mention IRI-flavored items explicitly in that
>>context, rather than changing the definition from anyURI to RFC 3987.
>>
>>Felix
>>
>>Felix Sasaki wrote:
>>>
>>> Hi John,
>>>
>>> John Boyer wrote:
>>>>
>>>> Hi Felix,
>>>>
>>>> I would like to take this opportunity to provide a little context
>>>> for the response than that which appeared in the prior response. I
>>>> would then like to see whether that context helps to make the
>>>> response more satisfactory for now.
>>>>
>>>> First, the spec that we normatively reference, XML Schema 1.0 Second
>>>> Edition, defines xs:anyURI datatype in terms of RFC 2396, RFC 2732,
>>>> and the algorithm in Section 5.4 of XLink [1]. It does not refer to
>>>> RFC 3987 at all, as this document came out after XML Schema 1.0
>>>> Second Edition.
>>>
>>> that's exactly the point: XML Schema 1.0 does not refer to RFC 3987,
>>> since RFC 3987 was too late. Nevertheless, the xs:anyURI data type was
>>> designed to be compatible with the upcoming IRI specification.
>>>
>>>>
>>>>
>>>> The working group decided to defer to a future version upgrading the
>>>> XML Schema engines required by XForms processors and design tools.
>>> in my opinion, no upgrade of the XML Schema engines is necessary. The
>>> reason that XML Schema 1.0 does not cite the IRI spec, is due to
>>> timing (which you described above), not due to technical issues.
>>>
>>>>
>>>> And the more important fact, which responds to your response, is that
>>>> the working group decided that upgrading to XPath 2.0 is a future
>>>> feature scheduled for XForms 2.0, so the citation you gave of XPath
>>>> 2.0 amounts to another pointer to a feature that is not within the
>>>> scope of XForms 1.1.
>>>
>>> I hope that my explanation above makes clear that a reference to IRI
>>> will not require an implementation change for XML Schema engines
>>> required by XForms processors.
>>>
>>>> In other words, all of this functionality is amounting to requests
>>>> for features that are not in the XForms 1.1 requirements
>>>> (<<http://www.w3.org/TR/xforms-11-req/>
http://www.w3.org/TR/xforms-11-req/>http://www.w3.org/TR/xforms-11-req/).
>>>
>>> Me / the i18n core Working Group don't have a new feature request, but
>>> a request for clarification in existing features. My reference to
>>> XPath 2.0 also was a reference to a clarifying note in that
>>> specification, and not a request to implement features unique to it.
>>>
>>>>
>>>> So, our response was not rejecting the request, but rather committing
>>>> to adding this issue into the requirements stream of the appropriate
>>>> version of XForms containing numerous requirements related to this
>>>> request,
>>>>
>>>> Could you let us know if this information makes it possible to accept
>>>> the resolution (understood grudgingly) with the understanding that it
>>>> is on the agenda for our future.
>>>
>>> I'm sorry, but personally I'm not yet convinced. Other participants
>>> from the i18n core WG might provide input on this thread, and we will
>>> come back with a Working Group reply after our next call this week
>>> (Tuesday).
>>>
>>> Felix
>>>
>>>
>>
>>
>
>
>#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
>#-#-# <http://www.sw.it.aoyama.ac.jp/>http://www.sw.it.aoyama.ac.jp
mailto:duerst@it.aoyama.ac.jp
>
>
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp