Re: [XForms 1.1] i18n comment: IRIs for external schema locations possible? (PR#8)

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

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

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

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

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





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 .

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/).
>
> 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
>
>