W3C home > Mailing lists > Public > public-xhtml2@w3.org > October 2008

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

From: <boyerj@ca.ibm.com>
Date: Tue, 7 Oct 2008 08:22:43 -0500
Message-Id: <200810071322.m97DMh3J024451@htmlwg.mn.aptest.com>
To: public-xhtml2@w3.org
CC: xhtml2-issues@mn.aptest.com


This is a multipart message in MIME format.
--=_alternative 001FF960882574DB_=
Content-Type: text/plain; charset="US-ASCII"

The Forms WG discussed the issue below at its last face to face meeting, 
and I see now that the action item to send this note to XHTML2 "fell off 
the side of my desk" so to speak.

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?

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@ca.ibm.com 

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


--=_alternative 001FF960882574DB_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">The Forms WG discussed the issue below
at its last face to face meeting, and I see now that the action item to
send this note to XHTML2 &quot;fell off the side of my desk&quot; so to
speak.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">The template content may contain elements
with IDs. &nbsp;Such languages define (or should define) rules for how
to handle IDREFs to repeated elements with IDs. &nbsp;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.</font>
<br>
<br><font size=2 face="sans-serif">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:</font>
<br>
<br><font size=2 face="sans-serif">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. &nbsp;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.</font>
<br>
<br><font size=2 face="sans-serif">2) Suppose you have an access element
*inside* of a repeat whose targetid indicates an element within the same
repeat. &nbsp;The repeat will iterate the access element in each &quot;repeat
item&quot;. &nbsp;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. &nbsp;Is it appropriate for the access element to be scoped to
operating within the containing repeat item?</font>
<br>
<br><font size=2 face="sans-serif">Cheers,</font>
<br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br>
STSM, Interactive Documents and Web 2.0 Applications<br>
Chair, W3C Forms Working Group<br>
Workplace, Portal and Collaboration Software<br>
IBM Victoria Software Lab<br>
E-Mail: boyerj@ca.ibm.com &nbsp;<br>
<br>
Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br>
Blog RSS feed: </font><a href="http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw"><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw</font></a><font size=2 face="sans-serif"><br>
<br>
</font>
--=_alternative 001FF960882574DB_=--
Received on Tuesday, 7 October 2008 13:23:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 18:12:50 GMT