Re: LC comment on access module usage with XForms (PR#8054)

John,

This is a formal response to the XForms last call comments on the XHTML Access
Module.  Please reply and indicate whether you accept the proposed resolution.

In general the working group feels that the issue of multiple elements having
the same XML ID is outside of the scope of this module.  In the vast majority of
cases this situation will never arise, since such a document would be invalid. 
We understand that in the context of XForms and its repeat element, it is
possible for multiple elements to have the same XML ID, since only one of those
elements is "active" at a time.  The working group feels that there is language
in XHTML Access already to handle the situation where a document changes (e.g.,
when an XML ID moves from one element to another).  Specifically:

"The location of the next matching element MUST be determined each time the
access element is triggered, since it is possible that between events the
contents of the document will have changed."

If XForms needs to impose additional constraints or provide additional advice to
authors and implementors, we believe it should be done in the context of the
XForms specification rather than the XHTML Access module.  We believe this is
similar to how XForms has dealt with CSS-related issues in the past.

Thanks in advance for your understanding of this decision.

Shane McCarron (on behalf of the XHTML 2 Working Group)

> The issue is how to handle the access element in the context of documents 
> with a run-time execution model that includes some sort of dynamic content 
> generation.
> 
> The main example that came to mind was the XForms repeat, which iterates 
> its content once for each node of data associated with the repeat by the 
> run-time execution model.
> 
> The template content may contain elements with IDs.  Such languages define 
> (or should define) rules for how to handle IDREFs to repeated elements 
> with IDs.  At a minimum, a note about the existence of such markup 
> languages seems warranted, along with advice to suggest that IDREF 
> resolution is done according to that language.
> 
> To ensure you fully consider whether you want to go with this suggestion 
> please note that the IDREF resolution method in XForms has two properties 
> to consider:
> 
> 1) Suppose you have an access element in a document, suppose you have a 
> repeat element as its following sibling, and suppose the targetid of the 
> access element indicates an element within the repeat.  Since the access 
> element is outside of the repeat, the XForms IDREF method would provide 
> the run-time element that matched both the requested ID and the current 
> index of the repeat.
> 
> 2) Suppose you have an access element *inside* of a repeat whose targetid 
> indicates an element within the same repeat.  The repeat will iterate the 
> access element in each "repeat item".  The XForms IDREF method in this 
> case would resolve to the same repeat item whether or not the repeat item 
> is the one currently indexed.  Is it appropriate for the access element to 
> be scoped to operating within the containing repeat item?

Received on Saturday, 18 October 2008 16:25:16 UTC