XForms 1.1 Disposition of Comments

14 November 2007

This version:

http://www.w3.org/MarkUp/Forms/2007/xforms11-lc-doc-20071114.html

Latest version:

http://www.w3.org/MarkUp/Forms/2007/xforms11-lc-doc.html

Editors:

John M. Boyer, IBM

Ulrich Nicolas Lissé, DreamLab

Steven Pemberton, CWI/W3C

Nick Van den Bleeken, Inventive Designers n.v.

Copyright ©2000 W3C^® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

Abstract

This note outlines the way in which the XForms Working Group has addressed comments received to date against working drafts of XForms 1.1

Status of this document

During the development of XForms 1.1, many public drafts of the document have been made available, and many public comments received. This document summarizes those comments and describes the ways in which the comments were addressed by the XForms Working Group.

Note that the majority of this document is automatically generated from the Working Group's database of comments. As such, it may contain typographical or stylistic errors. If so, these are contained in the original submissions, and the XForms Working Group elected to not change these submissions.

This document is a Note of the W3C's XForms Working Group. This Note may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Notes as reference material or to cite them as other than "work in progress". This document is work in progress and does not imply endorsement by the W3C membership.

This document has been produced as part of the W3C Forms Activity. The goals of the Forms Working Group (members only) are discussed in the Forms Working Group charter (members only).

Please send detailed comments on this document to www-forms-editor@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate. Public discussion on XForms features takes place on the mailing list www-forms@w3.org.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

Table of Contents

1. Actions

1.1 "This action has special deferred update behavior."

PROBLEM ID: 84

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  A minor comment on the wording "This action has special deferred update
  behavior."
  
  I am wondering what's so "special" about it - that is, besides the fact
  that it is subject to deferred update behavior. The wording suggests to
  me that not only are these actions subject to deferred update behavior,
  but that somehow there is something particularly unusual going on, which
  is not the case.
  
  I would just say that "This action is subject to deferred update  
  behavior.".
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Erik,
  
  we agree. The referenced sections will be changed.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  
  > A minor comment on the wording "This action has special deferred update
  > behavior."
  > 
  > I am wondering what's so "special" about it - that is, besides the fact
  > that it is subject to deferred update behavior. The wording suggests to
  > me that not only are these actions subject to deferred update behavior,
  > but that somehow there is something particularly unusual going on, which
  > is not the case.
  > 
  > I would just say that "This action is subject to deferred update  
  > behavior.".
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

1.2 [LC] 10.13 The prompt Action Element

PROBLEM ID: 74

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree

NOTES:

  We removed the prompt element, which we do not believe will result in
  objections
  because the element was not implementable in the general case due to
  restrictions it had to make on event flow and UI content.  The working group
  realized it could implement very similar functionality with no processing model
  hacks using group relevance, and deferred the ability to pop up a separate
  dialog with that functionality to a future release.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#action-prompt
  
  Why isn't <message> sufficient for this?
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Steven,
  
  message is not suffcient for this usecase. However, we decided to remove the
  prompt action from XForms 1.1 since it creates more problems than it solves.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  > http://www.w3.org/TR/xforms11/#action-prompt
  > 
  > Why isn't <message> sufficient for this?
  > 
  > 

1.3 XForms value attribute

PROBLEM ID: 25

STATE: Suspended
EDIT: Substantive
RESOLUTION: Defer
USER POSITION: No Response

NOTES:

  Future version.
  See John's reply at:
  http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0044.html

ORIGINAL MESSAGE:

  From: "Andrew Bonard" <Andrew.Bonard@harlandfs.com>
  
  
  
  Hello,
  
  I'd like to suggest that we have a value attribute that can be used
  on the send element in section 10.11. The optional attribute would
  contain an XPath expression to evaluate using the in-scope evaluation
  context. The result of the XPath expression is the submission identity.
  
  The markup might look something like:
  
  <action>
            <send value="concat('submission_', ../defaultSendLocation)"/>
  </action>
  
  My feeling is that the attribute would allow for a more dynamic and
  configurable binding to the submission element.
  
  Regards,
  
  Andrew Bonard
  
  
  

1.4 XForms 1.1 LC comment on insert and delete

PROBLEM ID: 51

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Defer
USER POSITION: No Response

NOTES:

  Resolved June 15, 2007 to make better examples in XForms 1.1 and defer
  additional actions to XForms 1.2
  (http://lists.w3.org/Archives/Public/public-forms/2007Jun/att-0041/20070615.html#ACTION7)

ORIGINAL MESSAGE:

  From: "Mark Birbeck" <mark.birbeck@x-port.net>
  
  
  Although incredibly powerful, I feel that the latest versions of
  insert and delete are just too complicated for use in day-to-day form
  building. I find that I am constantly forced to look at examples in
  the spec or our tutorials, especially when dealing with attributes.
  And worse, if looking at mark-up from other authors, I find it takes a
  while to work out what it is that some code is doing.
  
  The core of the problem is the way that the attributes behave when
  used in combination, which often requires reference to documentation
  to be completely sure that you've got it right.
  
  I have no immediate suggestions as to how to resolve this, but I would
  say that in general it is easier to code if there are a number of
  actions that do something small and specific, rather than one action
  that does a lot. So, for example, copying a node from one instance to
  another is probably easier to understand if the action is called
  'copy' or 'duplicate'. The fact that an 'insertion' takes place seems
  secondary, and it's even possible that a node will be overwritten
  rather than inserted.
  
  Regards,
  
  Mark
  
  -- 
     Mark Birbeck, formsPlayer
  
     mark.birbeck@x-port.net | +44 (0) 20 7689 9232
     http://www.formsPlayer.com | http://internet-apps.blogspot.com
  
     standards. innovation.
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Mark,
  
  we agree. We are about to create new descriptive example tables for insert and
  delete using one set of instance data. In general, nodeset is used when you want
  to pick one of the children of a node and insert before or after that node, and
  context is used when you want to append or prepend a child inside a node. In
  future versions of XForms we may add more dedicated actions which are
  essentially shortcuts to insert/delete.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  > Although incredibly powerful, I feel that the latest versions of
  > insert and delete are just too complicated for use in day-to-day form
  > building. I find that I am constantly forced to look at examples in
  > the spec or our tutorials, especially when dealing with attributes.
  > And worse, if looking at mark-up from other authors, I find it takes a
  > while to work out what it is that some code is doing.
  > 
  > The core of the problem is the way that the attributes behave when
  > used in combination, which often requires reference to documentation
  > to be completely sure that you've got it right.
  > 
  > I have no immediate suggestions as to how to resolve this, but I would
  > say that in general it is easier to code if there are a number of
  > actions that do something small and specific, rather than one action
  > that does a lot. So, for example, copying a node from one instance to
  > another is probably easier to understand if the action is called
  > 'copy' or 'duplicate'. The fact that an 'insertion' takes place seems
  > secondary, and it's even possible that a node will be overwritten
  > rather than inserted.
  > 
  > Regards,
  > 
  > Mark
  > 
  > -- 
  >    Mark Birbeck, formsPlayer
  > 
  >    mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  >    http://www.formsPlayer.com | http://internet-apps.blogspot.com
  > 
  >    standards. innovation.
  > 
  > 

1.5 last call comments for Section 10

PROBLEM ID: 47

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response

NOTES:

  Almost all editorial except our ultimate handling of #19 in the list.
  We removed the prompt element, which we do not believe will result in objections
  because the element was not implementable in the general case due to
  restrictions it had to make on event flow and UI content.  The working group
  realized it could implement very similar functionality with no processing model
  hacks using group relevance, and deferred the ability to pop up a separate
  dialog with that functionality to a future release.

ORIGINAL MESSAGE:

  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  
  
  Hi all,
  
  Sorry, I only got through section 10 this weekend.  I'll try to get section
  11 done in the next day or two.  Here is what I came up with:
  
  1) Section 10 - under 'Deferred Updates' - first sentence has a space
  before the period.
  2) Section 10 - last sentence before section 10.1 - 'peformed' misspelled.
  3) Section 10.2 - the 'delay' attribute - it mentions that the default
  value is 0.  I would think that there might be some value for some xforms
  processors to emulate JS's (and other systems ideas for timers like Windows
  and OS/2) where a value of 0 is the shortest amount of delay possible but
  it is still somewhat of a delay in that the processing could then be
  performed on a separate thread.  Whereas if no delay attribute is specified
  at all, then it would be performed immediately.  Just a thought.
  4) Section 10.2.1 - first sentence - should probably be 'provides', not
  'provide' since it is a singular noun.  Also I'm not sure if it should be
  'an alternative means' or 'an alternate means'.
  5) Section 10.2.2 - same as 10.2.1
  6) The 'child elements' of the different actions like <name>, <target>,
  <delay>, <control>, etc. are not defined in the schema.
  7) I had a personal issue with the child elements like the ones I mentioned
  in my #6.  They kind of interrupt the flow of the spec.  The action is
  partially described (i.e. the special attributes are spelled out), then the
  child elements are described in detail, then the behavior of the action is
  described in detail.  But sometimes this behavior of the action is
  described amongst the descriptions of the child elements.  It really needs
  to be separated out.  It might just be me who sees this as an issue.  But I
  think that if I am writing my action the old-styled way (i.e. using attrs
  and not child elements) then I should be able to get all of the information
  that I need without reading any part of the child element descriptions and
  that the information I'd need would all be available BEFORE the child
  elements are described.  For example, there is a lot of information about
  how 'delay' works on a xf:dispatch...how an event is added to an event
  queue and what to do if it is already on the queue.  This has nothing
  specifically to do with the 'delay child element', but it is all described
  in that section.  So if I were an author going through this spec trying to
  figure out how I wanted to write my action, I'd have to read through almost
  two pages of information before I get to that little tidbit.
  8) Section 10.2.3 - the 'if' attribute is mentioned for the first time.  It
  seemed to me that this popped out of the middle of nowhere.  I'd suggest
  that 'if' and 'while' should be mentioned at least in passing in Section 10
  where 'Conditional Execution of XForms Actions' and 'Iteration of XForms
  Actions' are brought up.
  9) Section 10.3 - first sentence - 'This action causes the processing of
  xforms-rebuild to happen...'.  Maybe that would read better as '...the
  default processing...' or '...the default action...'?  If so, this sentence
  is used for the other RRRR events.
  10) Section 10.8 - 'If neither a value attribute nor text content are
  present, the effect is to set the value...'.  This sentence appears in the
  second example for the setvalue element.  It seems to me that perhaps this
  belongs in the main section describing setvalue rather than inside an
  example where it could be overlooked.
  11) Section 10.9 - 'Note that this event is implicitly invoked to implement
  XForms accessibility features such as accesskey'.  This sentence seems to
  pertain more to the xforms-focus event than to the setfocus element so
  maybe it should be moved to that section instead of having it here?
  12) Section 10.9.1 - 'The identity of the element to which the setfocus
  action dispatches xforms-focus is is'...one to many 'is's.
  13) Section 10.10 - @show - The 'if' that starts the second sentence needs
  to be capitalized.
  14) Section 10.10 - another example where the processing information is
  mentioned after the possible child element.
  15) Section 10.10.1 - The last sentence says, "If the load does not have a
  resource element as its first child, then the URI is obtained from the
  resource attribute or the Single Node Binding, if given."  That kind of
  makes it sound like a toss up.  But Section 10.10.2 goes on to define even
  more behavior in that area.  I think that the last sentence from Section
  10.10.1 and the first paragraph from Section 10.10.2 need to be combined
  together AND simplified.
  16) Section 10.11 - @submission description - mentions 'If this attribute
  is omitted, then the first submission in document order from the model
  associated with the in-scope evaluation context is used'.  Similar wording
  is used in other places in section 10.  How do you figure out the 'in-scope
  evaluation context'?  If xf:send or any of these other xforms actions are
  specified as a handler in a ev:listener, the xforms action could fire
  because of an event reaching any one of a number of elements in the
  document.  And how about if you have:
  
  <xf:model id="firstModel">
  ...
  </xf:model>
  
  <xf:model id="secondModel">
  ...
  </xf:model>
  
  
  <xf:trigger id="myTrigger" model="secondModel">
     <xf:label>click to activate</xf:label>
     <xf:send id="mySender" ev:event="DOMActivate"/>
  </xf:trigger>
  
  <html:button id="myButton.../>
  <ev:listener event="DOMActivate" observer="myButton" handler="#mySender"/>
  
  The in-scope evaluation context if "myTrigger" is clicked, I believe, would
  have the model being "secondModel" so now the first xf:submission will
  happen from that model.  But what about if I click on the html:button?  The
  in-scope evaluation would still be the secondModel, right?  Unless I missed
  something specific about the evaluation contexts for actions.  But I'd
  think that the submission that should happen would be the first
  xf:submission from the default model (the first one).  Or am I missing
  something?
  
  17) Section 10.12 - There is a note about deferred update behavior and what
  happens if a xf:output is inside a xf:message...that the refresh for the
  output happens right away, but if the output depends on a recalc happening,
  then the author has to call it specifically.  Should rebuild be mentioned
  here, too?
  18) 10.13 - I think that the first sentence for the prompt action element
  needs to be reworded.  I find the first sentence confusing and then each
  subsequent sentence goes into event behavior, bubbling, etc.  There needs
  to be a better description of what a prompt is, I think.  Until I got to
  the example where it makes it appear to be like a dialog box, I had no idea
  what it was.  There needs to be some more descriptive text.  Like, perhaps,
  "A form author can solicit simple feedback from the user by using a
  xf:prompt.  A combination of labels and triggers, a prompt can be used to
  halt the processing of a form until the user provides feedback by selecting
  one of the triggers in the prompt.  Similar to a modal message."
  19) Since labels are allowed in a xf:prompt and xf:outputs are allowed in
  labels, can xf:outputs be used in a prompt?  If so, do they behave
  similarly to how they behave in a xf:message?  In that they are
  automatically refreshed when the xf:prompt starts handling the event?
  
  I'll try to get to section 11 as soon as I have time.
  
  Thanks for listening,
  --Aaron
  IBM Corporation
  Internal Zip: 9022D016
  11501 Burnet Road
  Austin, TX 78758
  (512)838-9948
  inet: aaronr@us.ibm.com
     _
    (} @
    |=     Volleyball Rules!!!
  /\
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Aaron,
  
  all issues except for 3), 16) and 19) are considered to be editorial and we will
  fix the spec accordingly.
  
  Regarding issue 3) we change the spec language so that delay="" is the default
  and means synchronous dispatch with no delay; and delay="0" is asynchronous, and
  delay as a positive integer is a delay as currently specified.
  
  Regarding issue 16) we agree that the in-scope evaluation context is determined
  statically, by the lexical position of the handler definition, and so the
  secondModel default submission will be used.
  
  Regarding issue 19) we decided to mirror message.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  > Hi all,
  > 
  > Sorry, I only got through section 10 this weekend.  I'll try to get section
  > 11 done in the next day or two.  Here is what I came up with:
  > 
  > 1) Section 10 - under 'Deferred Updates' - first sentence has a space
  > before the period.
  > 2) Section 10 - last sentence before section 10.1 - 'peformed' misspelled.
  > 3) Section 10.2 - the 'delay' attribute - it mentions that the default
  > value is 0.  I would think that there might be some value for some xforms
  > processors to emulate JS's (and other systems ideas for timers like Windows
  > and OS/2) where a value of 0 is the shortest amount of delay possible but
  > it is still somewhat of a delay in that the processing could then be
  > performed on a separate thread.  Whereas if no delay attribute is specified
  > at all, then it would be performed immediately.  Just a thought.
  > 4) Section 10.2.1 - first sentence - should probably be 'provides', not
  > 'provide' since it is a singular noun.  Also I'm not sure if it should be
  > 'an alternative means' or 'an alternate means'.
  > 5) Section 10.2.2 - same as 10.2.1
  > 6) The 'child elements' of the different actions like <name>, <target>,
  > <delay>, <control>, etc. are not defined in the schema.
  > 7) I had a personal issue with the child elements like the ones I mentioned
  > in my #6.  They kind of interrupt the flow of the spec.  The action is
  > partially described (i.e. the special attributes are spelled out), then the
  > child elements are described in detail, then the behavior of the action is
  > described in detail.  But sometimes this behavior of the action is
  > described amongst the descriptions of the child elements.  It really needs
  > to be separated out.  It might just be me who sees this as an issue.  But I
  > think that if I am writing my action the old-styled way (i.e. using attrs
  > and not child elements) then I should be able to get all of the information
  > that I need without reading any part of the child element descriptions and
  > that the information I'd need would all be available BEFORE the child
  > elements are described.  For example, there is a lot of information about
  > how 'delay' works on a xf:dispatch...how an event is added to an event
  > queue and what to do if it is already on the queue.  This has nothing
  > specifically to do with the 'delay child element', but it is all described
  > in that section.  So if I were an author going through this spec trying to
  > figure out how I wanted to write my action, I'd have to read through almost
  > two pages of information before I get to that little tidbit.
  > 8) Section 10.2.3 - the 'if' attribute is mentioned for the first time.  It
  > seemed to me that this popped out of the middle of nowhere.  I'd suggest
  > that 'if' and 'while' should be mentioned at least in passing in Section 10
  > where 'Conditional Execution of XForms Actions' and 'Iteration of XForms
  > Actions' are brought up.
  > 9) Section 10.3 - first sentence - 'This action causes the processing of
  > xforms-rebuild to happen...'.  Maybe that would read better as '...the
  > default processing...' or '...the default action...'?  If so, this sentence
  > is used for the other RRRR events.
  > 10) Section 10.8 - 'If neither a value attribute nor text content are
  > present, the effect is to set the value...'.  This sentence appears in the
  > second example for the setvalue element.  It seems to me that perhaps this
  > belongs in the main section describing setvalue rather than inside an
  > example where it could be overlooked.
  > 11) Section 10.9 - 'Note that this event is implicitly invoked to implement
  > XForms accessibility features such as accesskey'.  This sentence seems to
  > pertain more to the xforms-focus event than to the setfocus element so
  > maybe it should be moved to that section instead of having it here?
  > 12) Section 10.9.1 - 'The identity of the element to which the setfocus
  > action dispatches xforms-focus is is'...one to many 'is's.
  > 13) Section 10.10 - @show - The 'if' that starts the second sentence needs
  > to be capitalized.
  > 14) Section 10.10 - another example where the processing information is
  > mentioned after the possible child element.
  > 15) Section 10.10.1 - The last sentence says, "If the load does not have a
  > resource element as its first child, then the URI is obtained from the
  > resource attribute or the Single Node Binding, if given."  That kind of
  > makes it sound like a toss up.  But Section 10.10.2 goes on to define even
  > more behavior in that area.  I think that the last sentence from Section
  > 10.10.1 and the first paragraph from Section 10.10.2 need to be combined
  > together AND simplified.
  > 16) Section 10.11 - @submission description - mentions 'If this attribute
  > is omitted, then the first submission in document order from the model
  > associated with the in-scope evaluation context is used'.  Similar wording
  > is used in other places in section 10.  How do you figure out the 'in-scope
  > evaluation context'?  If xf:send or any of these other xforms actions are
  > specified as a handler in a ev:listener, the xforms action could fire
  > because of an event reaching any one of a number of elements in the
  > document.  And how about if you have:
  > 
  > <xf:model id="firstModel">
  > ...
  > </xf:model>
  > 
  > <xf:model id="secondModel">
  > ...
  > </xf:model>
  > 
  > 
  > <xf:trigger id="myTrigger" model="secondModel">
  >    <xf:label>click to activate</xf:label>
  >    <xf:send id="mySender" ev:event="DOMActivate"/>
  > </xf:trigger>
  > 
  > <html:button id="myButton.../>
  > <ev:listener event="DOMActivate" observer="myButton" handler="#mySender"/>
  > 
  > The in-scope evaluation context if "myTrigger" is clicked, I believe, would
  > have the model being "secondModel" so now the first xf:submission will
  > happen from that model.  But what about if I click on the html:button?  The
  > in-scope evaluation would still be the secondModel, right?  Unless I missed
  > something specific about the evaluation contexts for actions.  But I'd
  > think that the submission that should happen would be the first
  > xf:submission from the default model (the first one).  Or am I missing
  > something?
  > 
  > 17) Section 10.12 - There is a note about deferred update behavior and what
  > happens if a xf:output is inside a xf:message...that the refresh for the
  > output happens right away, but if the output depends on a recalc happening,
  > then the author has to call it specifically.  Should rebuild be mentioned
  > here, too?
  > 18) 10.13 - I think that the first sentence for the prompt action element
  > needs to be reworded.  I find the first sentence confusing and then each
  > subsequent sentence goes into event behavior, bubbling, etc.  There needs
  > to be a better description of what a prompt is, I think.  Until I got to
  > the example where it makes it appear to be like a dialog box, I had no idea
  > what it was.  There needs to be some more descriptive text.  Like, perhaps,
  > "A form author can solicit simple feedback from the user by using a
  > xf:prompt.  A combination of labels and triggers, a prompt can be used to
  > halt the processing of a form until the user provides feedback by selecting
  > one of the triggers in the prompt.  Similar to a modal message."
  > 19) Since labels are allowed in a xf:prompt and xf:outputs are allowed in
  > labels, can xf:outputs be used in a prompt?  If so, do they behave
  > similarly to how they behave in a xf:message?  In that they are
  > automatically refreshed when the xf:prompt starts handling the event?
  > 
  > I'll try to get to section 11 as soon as I have time.
  > 
  > Thanks for listening,
  > --Aaron
  > IBM Corporation
  > Internal Zip: 9022D016
  > 11501 Burnet Road
  > Austin, TX 78758
  > (512)838-9948
  > inet: aaronr@us.ibm.com
  >    _
  >   (} @
  >   |=     Volleyball Rules!!!
  > /\
  > 
  > 

1.6 [LC: editorial] 9.3.6 The delete Action

PROBLEM ID: 75

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#action-delete
  
  The last line but one has an extra double quote in the example on
        nodeset="item""/>
  
  

FOLLOWUP 1:

  From: John Boyer <xforms-issues@aptest.com>
  
  Hi John,
  
  Yes you are correct.  I had attempted to account for the absence of a statement
  about insertion or deletion when the insertion or deletion location node is the
  root node (the parent of the root element node), but I see now thanks to your
  feedback that combining that step with the material for the root element of an
  instance introduces a problem.
  
  So, the changes made to the latest editor's draft do swap the steps as you
  requested (see steps c and d) while also retaining a modified step b that only
  addresses the root node.
  
  Regarding the question you asked about the phrase "or the child list if the
  insert location node is empty" appearing now in part 6c, this phrase explains
  how to obtain the target location when the insert location node is empty.  In
  that case, the target location is the child list of the insert location node. 
  It is much easier to see that this is true by looking at the non-diff-marked
  version.
  
  Finally, note that the section on insert now appears in Chapter 10 with all the
  other actions.
  
  Please let us know if you find any other issues with insert and delete as your
  review of these sections is invaluable.
  
  Thank you,
  John Boyer
  
  > This is a multipart message in MIME format.
  > --=_alternative 001A595788257331_=
  > Content-Type: text/plain; charset="US-ASCII"
  > 
  > "Clark, John" <CLARKJ2@ccf.org> 
  > Sent by: www-forms-editor-request@w3.org
  > 08/06/2007 06:29 AM
  > 
  > To
  > www-forms-editor@w3.org
  > cc
  > 
  > Subject
  > RE: Fw: [XForms 1.1] Inserting into an empty element (section  9.3.5 
  > processing (PR#172)
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  >> Hi John,
  >> Yes, it was an omission of the spec, and insertion into an 
  >> empty node was intended.
  >> 
  >> The latest editor's draft available from the Forms WG home 
  >> page contains a correction.  Please see the diff-marked 
  >> version.  Also, please note that step 6 received other 
  >> modifications due to addressing other last call comments, so 
  >> the fix needed to address your specific issue is at the end 
  >> of step 6c.  Please let us know if you have any further 
  >> concerns about this issue.
  > 
  > Could you please explain what the phrase "or the child list if the
  > 'insert location node' is empty" means?  What is the "child list"?  What
  > does it mean to insert a node before the child list of another node?
  > 
  > Also, as I read the latest diff-marked version of section 9.3.5[0], I am
  > concerned that it is impossible to insert a (non-attribute) node as a
  > child of an element that has no children and is the root element of an
  > instance.
  > 
  > Consider the "Append new person" trigger in the first example in that
  > section.  In this example, when this trigger first receives the
  > DOMActivate event the "insert context" is `instance('people')`, the Node
  > Set Binding node-set is the empty node-set, the "origin node-set" is
  > `instance('personProto')`, and the "insert location node" is
  > `instance('people')`.  Now, to determine the "target location", we use
  > rule 6.  Subrule "a." does not apply, since the cloned node is an
  > element.  Moving to subrule "b.", since the "insert location node" is
  > the root element of the 'people' instance, the root element of the
  > 'people' instance becomes the "target location".  Thus, in rule 7, since
  > the "target location" is "the root element of an instance, then the
  > cloned node replaces the instance root element."  I don't think this was
  > the intent of that example.
  > 
  > I believe that swapping subrules "b." and "c." would solve this problem.
  > 
  > [0]
  > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in
  > sert
  > 
  > Take care,
  > 
  >     John L. Clark
  > 
  > ===================================
  > 
  > Cleveland Clinic is ranked one of the top hospitals
  > in America by U.S. News & World Report (2007). 
  > Visit us online at http://www.clevelandclinic.org for
  > a complete listing of our services, staff and
  > locations.
  > 
  > 
  > Confidentiality Note:  This message is intended for use
  > only by the individual or entity to which it is addressed
  > and may contain information that is privileged,
  > confidential, and exempt from disclosure under applicable
  > law.  If the reader of this message is not the intended
  > recipient or the employee or agent responsible for
  > delivering the message to the intended recipient, you are
  > hereby notified that any dissemination, distribution or
  > copying of this communication is strictly prohibited.  If
  > you have received this communication in error,  please
  > contact the sender immediately and destroy the material in
  > its entirety, whether electronic or hard copy.  Thank you.
  > 
  > 
  > 
  > 
  > 
  > --=_alternative 001A595788257331_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John"
  > <CLARKJ2@ccf.org></b> </font>
  > <br><font size=1 face="sans-serif">Sent by:
  > www-forms-editor-request@w3.org</font>
  > <p><font size=1 face="sans-serif">08/06/2007 06:29 AM</font>
  > <td width=59%>
  > <table width=100%>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">To</font></div>
  > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">cc</font></div>
  > <td>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">Subject</font></div>
  > <td><font size=1 face="sans-serif">RE: Fw: [XForms 1.1] Inserting into
  > an empty element (section  9.3.5 processing (PR#172)</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><tt><font size=2><br>
  > > Hi John,<br>
  > > Yes, it was an omission of the spec, and insertion into an <br>
  > > empty node was intended.<br>
  > > <br>
  > > The latest editor's draft available from the Forms WG home <br>
  > > page contains a correction.  Please see the diff-marked <br>
  > > version.  Also, please note that step 6 received other <br>
  > > modifications due to addressing other last call comments, so <br>
  > > the fix needed to address your specific issue is at the end <br>
  > > of step 6c.  Please let us know if you have any further <br>
  > > concerns about this issue.<br>
  > <br>
  > Could you please explain what the phrase "or the child list if the<br>
  > 'insert location node' is empty" means?  What is the "child
  > list"?  What<br>
  > does it mean to insert a node before the child list of another node?<br>
  > <br>
  > Also, as I read the latest diff-marked version of section 9.3.5[0], I am<br>
  > concerned that it is impossible to insert a (non-attribute) node as a<br>
  > child of an element that has no children and is the root element of an<br>
  > instance.<br>
  > <br>
  > Consider the "Append new person" trigger in the first example
  > in that<br>
  > section.  In this example, when this trigger first receives the<br>
  > DOMActivate event the "insert context" is `instance('people')`,
  > the Node<br>
  > Set Binding node-set is the empty node-set, the "origin node-set"
  > is<br>
  > `instance('personProto')`, and the "insert location node" is<br>
  > `instance('people')`.  Now, to determine the "target location",
  > we use<br>
  > rule 6.  Subrule "a." does not apply, since the cloned node
  > is an<br>
  > element.  Moving to subrule "b.", since the "insert
  > location node" is<br>
  > the root element of the 'people' instance, the root element of the<br>
  > 'people' instance becomes the "target location".  Thus,
  > in rule 7, since<br>
  > the "target location" is "the root element of an instance,
  > then the<br>
  > cloned node replaces the instance root element."  I don't think
  > this was<br>
  > the intent of that example.<br>
  > <br>
  > I believe that swapping subrules "b." and "c." would
  > solve this problem.<br>
  > <br>
  > [0]<br>
  > </font></tt><a href="http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in"><tt><font
  > size=2>http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in</font></tt></a><tt><font
  > size=2><br>
  > sert<br>
  > <br>
  > Take care,<br>
  > <br>
  >     John L. Clark<br>
  > <br>
  > ===================================<br>
  > <br>
  > Cleveland Clinic is ranked one of the top hospitals<br>
  > in America by U.S. News & World Report (2007).  <br>
  > Visit us online at </font></tt><a
  href=http://www.clevelandclinic.org/><tt><font
  > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2>
  > for<br>
  > a complete listing of our services, staff and<br>
  > locations.<br>
  > <br>
  > <br>
  > Confidentiality Note:  This message is intended for use<br>
  > only by the individual or entity to which it is addressed<br>
  > and may contain information that is privileged,<br>
  > confidential, and exempt from disclosure under applicable<br>
  > law.  If the reader of this message is not the intended<br>
  > recipient or the employee or agent responsible for<br>
  > delivering the message to the intended recipient, you are<br>
  > hereby notified that any dissemination, distribution or<br>
  > copying of this communication is strictly prohibited.  If<br>
  > you have received this communication in error,  please<br>
  > contact the sender immediately and destroy the material in<br>
  > its entirety, whether electronic or hard copy.  Thank you.<br>
  > <br>
  > <br>
  > <br>
  > <br>
  > </font></tt>
  > --=_alternative 001A595788257331_=--
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  This has been fixed.  Please see the editor's draft available from the Forms WG
  website.
  
  Thanks,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#action-delete
  > 
  > The last line but one has an extra double quote in the example on
  >       nodeset="item""/>
  > 
  > 
  > 

REPLY 2:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi John,
  
  Yes you are correct.  I had attempted to account for the absence of a statement
  about insertion or deletion when the insertion or deletion location node is the
  root node (the parent of the root element node), but I see now thanks to your
  feedback that combining that step with the material for the root element of an
  instance introduces a problem.
  
  So, the changes made to the latest editor's draft do swap the steps as you
  requested (see steps c and d) while also retaining a modified step b that only
  addresses the root node.
  
  Regarding the question you asked about the phrase "or the child list if the
  insert location node is empty" appearing now in part 6c, this phrase explains
  how to obtain the target location when the insert location node is empty.  In
  that case, the target location is the child list of the insert location node. 
  It is much easier to see that this is true by looking at the non-diff-marked
  version.
  
  Finally, note that the section on insert now appears in Chapter 10 with all the
  other actions.
  
  Please let us know if you find any other issues with insert and delete as your
  review of these sections is invaluable.
  
  Thank you,
  John Boyer
  
  > This is a multipart message in MIME format.
  > --=_alternative 001A595788257331_=
  > Content-Type: text/plain; charset="US-ASCII"
  > 
  > "Clark, John" <CLARKJ2@ccf.org> 
  > Sent by: www-forms-editor-request@w3.org
  > 08/06/2007 06:29 AM
  > 
  > To
  > www-forms-editor@w3.org
  > cc
  > 
  > Subject
  > RE: Fw: [XForms 1.1] Inserting into an empty element (section  9.3.5 
  > processing (PR#172)
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  >> Hi John,
  >> Yes, it was an omission of the spec, and insertion into an 
  >> empty node was intended.
  >> 
  >> The latest editor's draft available from the Forms WG home 
  >> page contains a correction.  Please see the diff-marked 
  >> version.  Also, please note that step 6 received other 
  >> modifications due to addressing other last call comments, so 
  >> the fix needed to address your specific issue is at the end 
  >> of step 6c.  Please let us know if you have any further 
  >> concerns about this issue.
  > 
  > Could you please explain what the phrase "or the child list if the
  > 'insert location node' is empty" means?  What is the "child list"?  What
  > does it mean to insert a node before the child list of another node?
  > 
  > Also, as I read the latest diff-marked version of section 9.3.5[0], I am
  > concerned that it is impossible to insert a (non-attribute) node as a
  > child of an element that has no children and is the root element of an
  > instance.
  > 
  > Consider the "Append new person" trigger in the first example in that
  > section.  In this example, when this trigger first receives the
  > DOMActivate event the "insert context" is `instance('people')`, the Node
  > Set Binding node-set is the empty node-set, the "origin node-set" is
  > `instance('personProto')`, and the "insert location node" is
  > `instance('people')`.  Now, to determine the "target location", we use
  > rule 6.  Subrule "a." does not apply, since the cloned node is an
  > element.  Moving to subrule "b.", since the "insert location node" is
  > the root element of the 'people' instance, the root element of the
  > 'people' instance becomes the "target location".  Thus, in rule 7, since
  > the "target location" is "the root element of an instance, then the
  > cloned node replaces the instance root element."  I don't think this was
  > the intent of that example.
  > 
  > I believe that swapping subrules "b." and "c." would solve this problem.
  > 
  > [0]
  > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in
  > sert
  > 
  > Take care,
  > 
  >     John L. Clark
  > 
  > ===================================
  > 
  > Cleveland Clinic is ranked one of the top hospitals
  > in America by U.S. News & World Report (2007). 
  > Visit us online at http://www.clevelandclinic.org for
  > a complete listing of our services, staff and
  > locations.
  > 
  > 
  > Confidentiality Note:  This message is intended for use
  > only by the individual or entity to which it is addressed
  > and may contain information that is privileged,
  > confidential, and exempt from disclosure under applicable
  > law.  If the reader of this message is not the intended
  > recipient or the employee or agent responsible for
  > delivering the message to the intended recipient, you are
  > hereby notified that any dissemination, distribution or
  > copying of this communication is strictly prohibited.  If
  > you have received this communication in error,  please
  > contact the sender immediately and destroy the material in
  > its entirety, whether electronic or hard copy.  Thank you.
  > 
  > 
  > 
  > 
  > 
  > --=_alternative 001A595788257331_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John"
  > <CLARKJ2@ccf.org></b> </font>
  > <br><font size=1 face="sans-serif">Sent by:
  > www-forms-editor-request@w3.org</font>
  > <p><font size=1 face="sans-serif">08/06/2007 06:29 AM</font>
  > <td width=59%>
  > <table width=100%>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">To</font></div>
  > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">cc</font></div>
  > <td>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">Subject</font></div>
  > <td><font size=1 face="sans-serif">RE: Fw: [XForms 1.1] Inserting into
  > an empty element (section  9.3.5 processing (PR#172)</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><tt><font size=2><br>
  > > Hi John,<br>
  > > Yes, it was an omission of the spec, and insertion into an <br>
  > > empty node was intended.<br>
  > > <br>
  > > The latest editor's draft available from the Forms WG home <br>
  > > page contains a correction.  Please see the diff-marked <br>
  > > version.  Also, please note that step 6 received other <br>
  > > modifications due to addressing other last call comments, so <br>
  > > the fix needed to address your specific issue is at the end <br>
  > > of step 6c.  Please let us know if you have any further <br>
  > > concerns about this issue.<br>
  > <br>
  > Could you please explain what the phrase "or the child list if the<br>
  > 'insert location node' is empty" means?  What is the "child
  > list"?  What<br>
  > does it mean to insert a node before the child list of another node?<br>
  > <br>
  > Also, as I read the latest diff-marked version of section 9.3.5[0], I am<br>
  > concerned that it is impossible to insert a (non-attribute) node as a<br>
  > child of an element that has no children and is the root element of an<br>
  > instance.<br>
  > <br>
  > Consider the "Append new person" trigger in the first example
  > in that<br>
  > section.  In this example, when this trigger first receives the<br>
  > DOMActivate event the "insert context" is `instance('people')`,
  > the Node<br>
  > Set Binding node-set is the empty node-set, the "origin node-set"
  > is<br>
  > `instance('personProto')`, and the "insert location node" is<br>
  > `instance('people')`.  Now, to determine the "target location",
  > we use<br>
  > rule 6.  Subrule "a." does not apply, since the cloned node
  > is an<br>
  > element.  Moving to subrule "b.", since the "insert
  > location node" is<br>
  > the root element of the 'people' instance, the root element of the<br>
  > 'people' instance becomes the "target location".  Thus,
  > in rule 7, since<br>
  > the "target location" is "the root element of an instance,
  > then the<br>
  > cloned node replaces the instance root element."  I don't think
  > this was<br>
  > the intent of that example.<br>
  > <br>
  > I believe that swapping subrules "b." and "c." would
  > solve this problem.<br>
  > <br>
  > [0]<br>
  > </font></tt><a href="http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in"><tt><font
  > size=2>http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in</font></tt></a><tt><font
  > size=2><br>
  > sert<br>
  > <br>
  > Take care,<br>
  > <br>
  >     John L. Clark<br>
  > <br>
  > ===================================<br>
  > <br>
  > Cleveland Clinic is ranked one of the top hospitals<br>
  > in America by U.S. News & World Report (2007).  <br>
  > Visit us online at </font></tt><a
  href=http://www.clevelandclinic.org/><tt><font
  > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2>
  > for<br>
  > a complete listing of our services, staff and<br>
  > locations.<br>
  > <br>
  > <br>
  > Confidentiality Note:  This message is intended for use<br>
  > only by the individual or entity to which it is addressed<br>
  > and may contain information that is privileged,<br>
  > confidential, and exempt from disclosure under applicable<br>
  > law.  If the reader of this message is not the intended<br>
  > recipient or the employee or agent responsible for<br>
  > delivering the message to the intended recipient, you are<br>
  > hereby notified that any dissemination, distribution or<br>
  > copying of this communication is strictly prohibited.  If<br>
  > you have received this communication in error,  please<br>
  > contact the sender immediately and destroy the material in<br>
  > its entirety, whether electronic or hard copy.  Thank you.<br>
  > <br>
  > <br>
  > <br>
  > <br>
  > </font></tt>
  > --=_alternative 001A595788257331_=--
  > 
  > 

1.7 Specify meaning of setfocus to controls that will soon exist

PROBLEM ID: 19

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: "John Boyer" <boyerj@ca.ibm.com>
  
  It is supposed to be the case that you can setfocus to a control that is
  within a repeat, like this:
  
  <trigger>
      <label>Send me to I2</label>
      <setfocus ev:event="DOMActivate" control="I2"/>
  </trigger>
  
  <repeat id="R" nodeset="a/b/c">
      <input id="I1" ...> ...</input>
      <input id="I2" ...> ...</input>
  </repeat>
  
  But the specification does not say what happens when the focus is sent to
  I2 on a newly created repeat item:
  
  <trigger>
      <label>Send me to I2</label>
      <action ev:event="DOMActivate" >
         <insert nodeset="a/b/c" ... />
         <setfocus control="I2"/>
      </action>
  </trigger>
  
  I believe that the focus should still arrive on I2 in the newly created
  set of UI controls, but this is because I believe that setfocus has a
  deferred behavior that is imposed at the end of xforms-refresh.
  
  This deferred behavior is not specified, so I wonder what other
  implementations are doing.  Either way, clearly the above markup (the
  second trigger) should not fail to set the focus, but a literal reading of
  the current spec would seem to imply that it does because the repeat index
  of R is increased as soon as the insert occurs, yet the corresponding
  controls do not exist until the next xforms-refresh.
  
  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
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  John,
  
  thank you for pointing this out. The proposed resolution is: The setfocus,
  toggle, and setindex actions will run the actions indicated by the
  deferred-update flags (which will clear the flags).
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  > It is supposed to be the case that you can setfocus to a control that is
  > within a repeat, like this:
  > 
  > <trigger>
  >     <label>Send me to I2</label>
  >     <setfocus ev:event="DOMActivate" control="I2"/>
  > </trigger>
  > 
  > <repeat id="R" nodeset="a/b/c">
  >     <input id="I1" ...> ...</input>
  >     <input id="I2" ...> ...</input>
  > </repeat>
  > 
  > But the specification does not say what happens when the focus is sent to
  > I2 on a newly created repeat item:
  > 
  > <trigger>
  >     <label>Send me to I2</label>
  >     <action ev:event="DOMActivate" >
  >        <insert nodeset="a/b/c" ... />
  >        <setfocus control="I2"/>
  >     </action>
  > </trigger>
  > 
  > I believe that the focus should still arrive on I2 in the newly created
  > set of UI controls, but this is because I believe that setfocus has a
  > deferred behavior that is imposed at the end of xforms-refresh.
  > 
  > This deferred behavior is not specified, so I wonder what other
  > implementations are doing.  Either way, clearly the above markup (the
  > second trigger) should not fail to set the focus, but a literal reading of
  > the current spec would seem to imply that it does because the repeat index
  > of R is increased as soon as the insert occurs, yet the corresponding
  > controls do not exist until the next xforms-refresh.
  > 
  > 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
  > 
  > 

1.8 Fw: [XForms 1.1] Inserting into an empty element (section 9.3.5 processing

PROBLEM ID: 175

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response

NOTES:

  See reply.

ORIGINAL MESSAGE:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 001A595788257331_=
  Content-Type: text/plain; charset="US-ASCII"
  
  "Clark, John" <CLARKJ2@ccf.org> 
  Sent by: www-forms-editor-request@w3.org
  08/06/2007 06:29 AM
  
  To
  www-forms-editor@w3.org
  cc
  
  Subject
  RE: Fw: [XForms 1.1] Inserting into an empty element (section  9.3.5 
  processing (PR#172)
  
  
  
  
  
  
  
  > Hi John,
  > Yes, it was an omission of the spec, and insertion into an 
  > empty node was intended.
  > 
  > The latest editor's draft available from the Forms WG home 
  > page contains a correction.  Please see the diff-marked 
  > version.  Also, please note that step 6 received other 
  > modifications due to addressing other last call comments, so 
  > the fix needed to address your specific issue is at the end 
  > of step 6c.  Please let us know if you have any further 
  > concerns about this issue.
  
  Could you please explain what the phrase "or the child list if the
  'insert location node' is empty" means?  What is the "child list"?  What
  does it mean to insert a node before the child list of another node?
  
  Also, as I read the latest diff-marked version of section 9.3.5[0], I am
  concerned that it is impossible to insert a (non-attribute) node as a
  child of an element that has no children and is the root element of an
  instance.
  
  Consider the "Append new person" trigger in the first example in that
  section.  In this example, when this trigger first receives the
  DOMActivate event the "insert context" is `instance('people')`, the Node
  Set Binding node-set is the empty node-set, the "origin node-set" is
  `instance('personProto')`, and the "insert location node" is
  `instance('people')`.  Now, to determine the "target location", we use
  rule 6.  Subrule "a." does not apply, since the cloned node is an
  element.  Moving to subrule "b.", since the "insert location node" is
  the root element of the 'people' instance, the root element of the
  'people' instance becomes the "target location".  Thus, in rule 7, since
  the "target location" is "the root element of an instance, then the
  cloned node replaces the instance root element."  I don't think this was
  the intent of that example.
  
  I believe that swapping subrules "b." and "c." would solve this problem.
  
  [0]
  http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in
  sert
  
  Take care,
  
      John L. Clark
  
  ===================================
  
  Cleveland Clinic is ranked one of the top hospitals
  in America by U.S. News & World Report (2007). 
  Visit us online at http://www.clevelandclinic.org for
  a complete listing of our services, staff and
  locations.
  
  
  Confidentiality Note:  This message is intended for use
  only by the individual or entity to which it is addressed
  and may contain information that is privileged,
  confidential, and exempt from disclosure under applicable
  law.  If the reader of this message is not the intended
  recipient or the employee or agent responsible for
  delivering the message to the intended recipient, you are
  hereby notified that any dissemination, distribution or
  copying of this communication is strictly prohibited.  If
  you have received this communication in error,  please
  contact the sender immediately and destroy the material in
  its entirety, whether electronic or hard copy.  Thank you.
  
  
  
  
  
  --=_alternative 001A595788257331_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <table width=100%>
  <tr valign=top>
  <td width=40%><font size=1 face="sans-serif"><b>&quot;Clark, John&quot;
  &lt;CLARKJ2@ccf.org&gt;</b> </font>
  <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font>
  <p><font size=1 face="sans-serif">08/06/2007 06:29 AM</font>
  <td width=59%>
  <table width=100%>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">To</font></div>
  <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">cc</font></div>
  <td>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">Subject</font></div>
  <td><font size=1 face="sans-serif">RE: Fw: [XForms 1.1] Inserting into
  an empty element (section &nbsp;9.3.5 processing (PR#172)</font></table>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br>
  <br>
  <br><tt><font size=2><br>
  &gt; Hi John,<br>
  &gt; Yes, it was an omission of the spec, and insertion into an <br>
  &gt; empty node was intended.<br>
  &gt; <br>
  &gt; The latest editor's draft available from the Forms WG home <br>
  &gt; page contains a correction. &nbsp;Please see the diff-marked <br>
  &gt; version. &nbsp;Also, please note that step 6 received other <br>
  &gt; modifications due to addressing other last call comments, so <br>
  &gt; the fix needed to address your specific issue is at the end <br>
  &gt; of step 6c. &nbsp;Please let us know if you have any further <br>
  &gt; concerns about this issue.<br>
  <br>
  Could you please explain what the phrase &quot;or the child list if the<br>
  'insert location node' is empty&quot; means? &nbsp;What is the &quot;child
  list&quot;? &nbsp;What<br>
  does it mean to insert a node before the child list of another node?<br>
  <br>
  Also, as I read the latest diff-marked version of section 9.3.5[0], I am<br>
  concerned that it is impossible to insert a (non-attribute) node as a<br>
  child of an element that has no children and is the root element of an<br>
  instance.<br>
  <br>
  Consider the &quot;Append new person&quot; trigger in the first example
  in that<br>
  section. &nbsp;In this example, when this trigger first receives the<br>
  DOMActivate event the &quot;insert context&quot; is `instance('people')`,
  the Node<br>
  Set Binding node-set is the empty node-set, the &quot;origin node-set&quot;
  is<br>
  `instance('personProto')`, and the &quot;insert location node&quot; is<br>
  `instance('people')`. &nbsp;Now, to determine the &quot;target location&quot;,
  we use<br>
  rule 6. &nbsp;Subrule &quot;a.&quot; does not apply, since the cloned node
  is an<br>
  element. &nbsp;Moving to subrule &quot;b.&quot;, since the &quot;insert
  location node&quot; is<br>
  the root element of the 'people' instance, the root element of the<br>
  'people' instance becomes the &quot;target location&quot;. &nbsp;Thus,
  in rule 7, since<br>
  the &quot;target location&quot; is &quot;the root element of an instance,
  then the<br>
  cloned node replaces the instance root element.&quot; &nbsp;I don't think
  this was<br>
  the intent of that example.<br>
  <br>
  I believe that swapping subrules &quot;b.&quot; and &quot;c.&quot; would
  solve this problem.<br>
  <br>
  [0]<br>
  </font></tt><a href="http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in"><tt><font size=2>http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in</font></tt></a><tt><font size=2><br>
  sert<br>
  <br>
  Take care,<br>
  <br>
   &nbsp; &nbsp;John L. Clark<br>
  <br>
  ===================================<br>
  <br>
  Cleveland Clinic is ranked one of the top hospitals<br>
  in America by U.S. News &amp; World Report (2007). &nbsp;<br>
  Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2>
  for<br>
  a complete listing of our services, staff and<br>
  locations.<br>
  <br>
  <br>
  Confidentiality Note: &nbsp;This message is intended for use<br>
  only by the individual or entity to which it is addressed<br>
  and may contain information that is privileged,<br>
  confidential, and exempt from disclosure under applicable<br>
  law. &nbsp;If the reader of this message is not the intended<br>
  recipient or the employee or agent responsible for<br>
  delivering the message to the intended recipient, you are<br>
  hereby notified that any dissemination, distribution or<br>
  copying of this communication is strictly prohibited. &nbsp;If<br>
  you have received this communication in error, &nbsp;please<br>
  contact the sender immediately and destroy the material in<br>
  its entirety, whether electronic or hard copy. &nbsp;Thank you.<br>
  <br>
  <br>
  <br>
  <br>
  </font></tt>
  --=_alternative 001A595788257331_=--
  

FOLLOWUP 1:

  From: John Boyer <xforms-issues@aptest.com>
  
  Hi John,
  
  Yes you are correct.  I had attempted to account for the absence of a statement
  about insertion or deletion when the insertion or deletion location node is the
  root node (the parent of the root element node), but I see now thanks to your
  feedback that combining that step with the material for the root element of an
  instance introduces a problem.
  
  So, the changes made to the latest editor's draft do swap the steps as you
  requested (see steps c and d) while also retaining a modified step b that only
  addresses the root node.
  
  Regarding the question you asked about the phrase "or the child list if the
  insert location node is empty" appearing now in part 6c, this phrase explains
  how to obtain the target location when the insert location node is empty.  In
  that case, the target location is the child list of the insert location node. 
  It is much easier to see that this is true by looking at the non-diff-marked
  version.
  
  Finally, note that the section on insert now appears in Chapter 10 with all the
  other actions.
  
  Please let us know if you find any other issues with insert and delete as your
  review of these sections is invaluable.
  
  Thank you,
  John Boyer
  
  > This is a multipart message in MIME format.
  > --=_alternative 001A595788257331_=
  > Content-Type: text/plain; charset="US-ASCII"
  > 
  > "Clark, John" <CLARKJ2@ccf.org> 
  > Sent by: www-forms-editor-request@w3.org
  > 08/06/2007 06:29 AM
  > 
  > To
  > www-forms-editor@w3.org
  > cc
  > 
  > Subject
  > RE: Fw: [XForms 1.1] Inserting into an empty element (section  9.3.5 
  > processing (PR#172)
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  >> Hi John,
  >> Yes, it was an omission of the spec, and insertion into an 
  >> empty node was intended.
  >> 
  >> The latest editor's draft available from the Forms WG home 
  >> page contains a correction.  Please see the diff-marked 
  >> version.  Also, please note that step 6 received other 
  >> modifications due to addressing other last call comments, so 
  >> the fix needed to address your specific issue is at the end 
  >> of step 6c.  Please let us know if you have any further 
  >> concerns about this issue.
  > 
  > Could you please explain what the phrase "or the child list if the
  > 'insert location node' is empty" means?  What is the "child list"?  What
  > does it mean to insert a node before the child list of another node?
  > 
  > Also, as I read the latest diff-marked version of section 9.3.5[0], I am
  > concerned that it is impossible to insert a (non-attribute) node as a
  > child of an element that has no children and is the root element of an
  > instance.
  > 
  > Consider the "Append new person" trigger in the first example in that
  > section.  In this example, when this trigger first receives the
  > DOMActivate event the "insert context" is `instance('people')`, the Node
  > Set Binding node-set is the empty node-set, the "origin node-set" is
  > `instance('personProto')`, and the "insert location node" is
  > `instance('people')`.  Now, to determine the "target location", we use
  > rule 6.  Subrule "a." does not apply, since the cloned node is an
  > element.  Moving to subrule "b.", since the "insert location node" is
  > the root element of the 'people' instance, the root element of the
  > 'people' instance becomes the "target location".  Thus, in rule 7, since
  > the "target location" is "the root element of an instance, then the
  > cloned node replaces the instance root element."  I don't think this was
  > the intent of that example.
  > 
  > I believe that swapping subrules "b." and "c." would solve this problem.
  > 
  > [0]
  > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in
  > sert
  > 
  > Take care,
  > 
  >     John L. Clark
  > 
  > ===================================
  > 
  > Cleveland Clinic is ranked one of the top hospitals
  > in America by U.S. News & World Report (2007). 
  > Visit us online at http://www.clevelandclinic.org for
  > a complete listing of our services, staff and
  > locations.
  > 
  > 
  > Confidentiality Note:  This message is intended for use
  > only by the individual or entity to which it is addressed
  > and may contain information that is privileged,
  > confidential, and exempt from disclosure under applicable
  > law.  If the reader of this message is not the intended
  > recipient or the employee or agent responsible for
  > delivering the message to the intended recipient, you are
  > hereby notified that any dissemination, distribution or
  > copying of this communication is strictly prohibited.  If
  > you have received this communication in error,  please
  > contact the sender immediately and destroy the material in
  > its entirety, whether electronic or hard copy.  Thank you.
  > 
  > 
  > 
  > 
  > 
  > --=_alternative 001A595788257331_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John"
  > <CLARKJ2@ccf.org></b> </font>
  > <br><font size=1 face="sans-serif">Sent by:
  > www-forms-editor-request@w3.org</font>
  > <p><font size=1 face="sans-serif">08/06/2007 06:29 AM</font>
  > <td width=59%>
  > <table width=100%>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">To</font></div>
  > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">cc</font></div>
  > <td>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">Subject</font></div>
  > <td><font size=1 face="sans-serif">RE: Fw: [XForms 1.1] Inserting into
  > an empty element (section  9.3.5 processing (PR#172)</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><tt><font size=2><br>
  > > Hi John,<br>
  > > Yes, it was an omission of the spec, and insertion into an <br>
  > > empty node was intended.<br>
  > > <br>
  > > The latest editor's draft available from the Forms WG home <br>
  > > page contains a correction.  Please see the diff-marked <br>
  > > version.  Also, please note that step 6 received other <br>
  > > modifications due to addressing other last call comments, so <br>
  > > the fix needed to address your specific issue is at the end <br>
  > > of step 6c.  Please let us know if you have any further <br>
  > > concerns about this issue.<br>
  > <br>
  > Could you please explain what the phrase "or the child list if the<br>
  > 'insert location node' is empty" means?  What is the "child
  > list"?  What<br>
  > does it mean to insert a node before the child list of another node?<br>
  > <br>
  > Also, as I read the latest diff-marked version of section 9.3.5[0], I am<br>
  > concerned that it is impossible to insert a (non-attribute) node as a<br>
  > child of an element that has no children and is the root element of an<br>
  > instance.<br>
  > <br>
  > Consider the "Append new person" trigger in the first example
  > in that<br>
  > section.  In this example, when this trigger first receives the<br>
  > DOMActivate event the "insert context" is `instance('people')`,
  > the Node<br>
  > Set Binding node-set is the empty node-set, the "origin node-set"
  > is<br>
  > `instance('personProto')`, and the "insert location node" is<br>
  > `instance('people')`.  Now, to determine the "target location",
  > we use<br>
  > rule 6.  Subrule "a." does not apply, since the cloned node
  > is an<br>
  > element.  Moving to subrule "b.", since the "insert
  > location node" is<br>
  > the root element of the 'people' instance, the root element of the<br>
  > 'people' instance becomes the "target location".  Thus,
  > in rule 7, since<br>
  > the "target location" is "the root element of an instance,
  > then the<br>
  > cloned node replaces the instance root element."  I don't think
  > this was<br>
  > the intent of that example.<br>
  > <br>
  > I believe that swapping subrules "b." and "c." would
  > solve this problem.<br>
  > <br>
  > [0]<br>
  > </font></tt><a href="http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in"><tt><font
  > size=2>http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in</font></tt></a><tt><font
  > size=2><br>
  > sert<br>
  > <br>
  > Take care,<br>
  > <br>
  >     John L. Clark<br>
  > <br>
  > ===================================<br>
  > <br>
  > Cleveland Clinic is ranked one of the top hospitals<br>
  > in America by U.S. News & World Report (2007).  <br>
  > Visit us online at </font></tt><a
  href=http://www.clevelandclinic.org/><tt><font
  > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2>
  > for<br>
  > a complete listing of our services, staff and<br>
  > locations.<br>
  > <br>
  > <br>
  > Confidentiality Note:  This message is intended for use<br>
  > only by the individual or entity to which it is addressed<br>
  > and may contain information that is privileged,<br>
  > confidential, and exempt from disclosure under applicable<br>
  > law.  If the reader of this message is not the intended<br>
  > recipient or the employee or agent responsible for<br>
  > delivering the message to the intended recipient, you are<br>
  > hereby notified that any dissemination, distribution or<br>
  > copying of this communication is strictly prohibited.  If<br>
  > you have received this communication in error,  please<br>
  > contact the sender immediately and destroy the material in<br>
  > its entirety, whether electronic or hard copy.  Thank you.<br>
  > <br>
  > <br>
  > <br>
  > <br>
  > </font></tt>
  > --=_alternative 001A595788257331_=--
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi John,
  
  Yes you are correct.  I had attempted to account for the absence of a statement
  about insertion or deletion when the insertion or deletion location node is the
  root node (the parent of the root element node), but I see now thanks to your
  feedback that combining that step with the material for the root element of an
  instance introduces a problem.
  
  So, the changes made to the latest editor's draft do swap the steps as you
  requested (see steps c and d) while also retaining a modified step b that only
  addresses the root node.
  
  Regarding the question you asked about the phrase "or the child list if the
  insert location node is empty" appearing now in part 6c, this phrase explains
  how to obtain the target location when the insert location node is empty.  In
  that case, the target location is the child list of the insert location node. 
  It is much easier to see that this is true by looking at the non-diff-marked
  version.
  
  Finally, note that the section on insert now appears in Chapter 10 with all the
  other actions.
  
  Please let us know if you find any other issues with insert and delete as your
  review of these sections is invaluable.
  
  Thank you,
  John Boyer
  
  > This is a multipart message in MIME format.
  > --=_alternative 001A595788257331_=
  > Content-Type: text/plain; charset="US-ASCII"
  > 
  > "Clark, John" <CLARKJ2@ccf.org> 
  > Sent by: www-forms-editor-request@w3.org
  > 08/06/2007 06:29 AM
  > 
  > To
  > www-forms-editor@w3.org
  > cc
  > 
  > Subject
  > RE: Fw: [XForms 1.1] Inserting into an empty element (section  9.3.5 
  > processing (PR#172)
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  >> Hi John,
  >> Yes, it was an omission of the spec, and insertion into an 
  >> empty node was intended.
  >> 
  >> The latest editor's draft available from the Forms WG home 
  >> page contains a correction.  Please see the diff-marked 
  >> version.  Also, please note that step 6 received other 
  >> modifications due to addressing other last call comments, so 
  >> the fix needed to address your specific issue is at the end 
  >> of step 6c.  Please let us know if you have any further 
  >> concerns about this issue.
  > 
  > Could you please explain what the phrase "or the child list if the
  > 'insert location node' is empty" means?  What is the "child list"?  What
  > does it mean to insert a node before the child list of another node?
  > 
  > Also, as I read the latest diff-marked version of section 9.3.5[0], I am
  > concerned that it is impossible to insert a (non-attribute) node as a
  > child of an element that has no children and is the root element of an
  > instance.
  > 
  > Consider the "Append new person" trigger in the first example in that
  > section.  In this example, when this trigger first receives the
  > DOMActivate event the "insert context" is `instance('people')`, the Node
  > Set Binding node-set is the empty node-set, the "origin node-set" is
  > `instance('personProto')`, and the "insert location node" is
  > `instance('people')`.  Now, to determine the "target location", we use
  > rule 6.  Subrule "a." does not apply, since the cloned node is an
  > element.  Moving to subrule "b.", since the "insert location node" is
  > the root element of the 'people' instance, the root element of the
  > 'people' instance becomes the "target location".  Thus, in rule 7, since
  > the "target location" is "the root element of an instance, then the
  > cloned node replaces the instance root element."  I don't think this was
  > the intent of that example.
  > 
  > I believe that swapping subrules "b." and "c." would solve this problem.
  > 
  > [0]
  > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in
  > sert
  > 
  > Take care,
  > 
  >     John L. Clark
  > 
  > ===================================
  > 
  > Cleveland Clinic is ranked one of the top hospitals
  > in America by U.S. News & World Report (2007). 
  > Visit us online at http://www.clevelandclinic.org for
  > a complete listing of our services, staff and
  > locations.
  > 
  > 
  > Confidentiality Note:  This message is intended for use
  > only by the individual or entity to which it is addressed
  > and may contain information that is privileged,
  > confidential, and exempt from disclosure under applicable
  > law.  If the reader of this message is not the intended
  > recipient or the employee or agent responsible for
  > delivering the message to the intended recipient, you are
  > hereby notified that any dissemination, distribution or
  > copying of this communication is strictly prohibited.  If
  > you have received this communication in error,  please
  > contact the sender immediately and destroy the material in
  > its entirety, whether electronic or hard copy.  Thank you.
  > 
  > 
  > 
  > 
  > 
  > --=_alternative 001A595788257331_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John"
  > <CLARKJ2@ccf.org></b> </font>
  > <br><font size=1 face="sans-serif">Sent by:
  > www-forms-editor-request@w3.org</font>
  > <p><font size=1 face="sans-serif">08/06/2007 06:29 AM</font>
  > <td width=59%>
  > <table width=100%>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">To</font></div>
  > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">cc</font></div>
  > <td>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">Subject</font></div>
  > <td><font size=1 face="sans-serif">RE: Fw: [XForms 1.1] Inserting into
  > an empty element (section  9.3.5 processing (PR#172)</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><tt><font size=2><br>
  > > Hi John,<br>
  > > Yes, it was an omission of the spec, and insertion into an <br>
  > > empty node was intended.<br>
  > > <br>
  > > The latest editor's draft available from the Forms WG home <br>
  > > page contains a correction.  Please see the diff-marked <br>
  > > version.  Also, please note that step 6 received other <br>
  > > modifications due to addressing other last call comments, so <br>
  > > the fix needed to address your specific issue is at the end <br>
  > > of step 6c.  Please let us know if you have any further <br>
  > > concerns about this issue.<br>
  > <br>
  > Could you please explain what the phrase "or the child list if the<br>
  > 'insert location node' is empty" means?  What is the "child
  > list"?  What<br>
  > does it mean to insert a node before the child list of another node?<br>
  > <br>
  > Also, as I read the latest diff-marked version of section 9.3.5[0], I am<br>
  > concerned that it is impossible to insert a (non-attribute) node as a<br>
  > child of an element that has no children and is the root element of an<br>
  > instance.<br>
  > <br>
  > Consider the "Append new person" trigger in the first example
  > in that<br>
  > section.  In this example, when this trigger first receives the<br>
  > DOMActivate event the "insert context" is `instance('people')`,
  > the Node<br>
  > Set Binding node-set is the empty node-set, the "origin node-set"
  > is<br>
  > `instance('personProto')`, and the "insert location node" is<br>
  > `instance('people')`.  Now, to determine the "target location",
  > we use<br>
  > rule 6.  Subrule "a." does not apply, since the cloned node
  > is an<br>
  > element.  Moving to subrule "b.", since the "insert
  > location node" is<br>
  > the root element of the 'people' instance, the root element of the<br>
  > 'people' instance becomes the "target location".  Thus,
  > in rule 7, since<br>
  > the "target location" is "the root element of an instance,
  > then the<br>
  > cloned node replaces the instance root element."  I don't think
  > this was<br>
  > the intent of that example.<br>
  > <br>
  > I believe that swapping subrules "b." and "c." would
  > solve this problem.<br>
  > <br>
  > [0]<br>
  > </font></tt><a href="http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in"><tt><font
  > size=2>http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in</font></tt></a><tt><font
  > size=2><br>
  > sert<br>
  > <br>
  > Take care,<br>
  > <br>
  >     John L. Clark<br>
  > <br>
  > ===================================<br>
  > <br>
  > Cleveland Clinic is ranked one of the top hospitals<br>
  > in America by U.S. News & World Report (2007).  <br>
  > Visit us online at </font></tt><a
  href=http://www.clevelandclinic.org/><tt><font
  > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2>
  > for<br>
  > a complete listing of our services, staff and<br>
  > locations.<br>
  > <br>
  > <br>
  > Confidentiality Note:  This message is intended for use<br>
  > only by the individual or entity to which it is addressed<br>
  > and may contain information that is privileged,<br>
  > confidential, and exempt from disclosure under applicable<br>
  > law.  If the reader of this message is not the intended<br>
  > recipient or the employee or agent responsible for<br>
  > delivering the message to the intended recipient, you are<br>
  > hereby notified that any dissemination, distribution or<br>
  > copying of this communication is strictly prohibited.  If<br>
  > you have received this communication in error,  please<br>
  > contact the sender immediately and destroy the material in<br>
  > its entirety, whether electronic or hard copy.  Thank you.<br>
  > <br>
  > <br>
  > <br>
  > <br>
  > </font></tt>
  > --=_alternative 001A595788257331_=--
  > 
  > 

1.9 XForms 1.1 comment - sample code error

PROBLEM ID: 31

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Gary F Stevens" <gfsteven@us.ibm.com>
  
  
  
  
  
  In section 10.14 of the specification there is an error in the provided
  sample code Handling Focus for Empty Repeats.  The second trigger control
  does not have an ending tag of </trigger>, but instead the tag </input>.
  
  Gary F Stevens
  gfsteven@us.ibm.com
  Software Group - Emerging Standards
  IBM/US/Raleigh-RTP
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Gary,
  
  You are right. We will update the spec accordingly. 
  
  Many thanks.
  
  Nick Van den Bleeken
  For the Forms WG
  
  > 
  > 
  > 
  > 
  > In section 10.14 of the specification there is an error in the provided
  > sample code Handling Focus for Empty Repeats.  The second trigger control
  > does not have an ending tag of </trigger>, but instead the tag </input>.
  > 
  > Gary F Stevens
  > gfsteven@us.ibm.com
  > Software Group - Emerging Standards
  > IBM/US/Raleigh-RTP
  > 
  > 

1.10 xf:insert and attribute order

PROBLEM ID: 105

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "paul butcher" <paul.butcher@formsplayer.com>
  
  
  In the Working Draft of 22 February 2007, Items 6a and 6b in section
  9.3.5, "The insert Action"
  (http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert)  both
  state that " If the cloned node is an attribute, then the target
  location is before the first attribute of the insert location node
  node."  Given the following, this directive is meaningless:
  
  According to XML,
  "the order of attribute specifications in a start-tag or empty-element
  tag is not significant."
  http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags
  
  According to XML Infoset, the attributes property of the element
  information item is "An unordered set of attribute information items,
  one for each of the attributes"
  http://www.w3.org/TR/xml-infoset/#infoitem.element
  
  Also, according to the DOM, one cannot insert attributes at a given
  location with insertBefore, appendChild, or replaceChild.  Therefore,
  the only way to achieve the mandated effect would be to remove each of
  the attributes, then set them again in the correct order.  However,
  given the above, I'm not sure that would be reliable.
  
  http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-1590626202
  
  and
  http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-952280727
  
  
  -- 
    Paul Butcher, formsPlayer
    paul.butcher@x-port.net
    www.formsPlayer.com  standards. innovation.
  
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Paul,
  
  we changed 6a and 6b to say that the insert location is the attribute list of
  the insert location node's parent element.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Form WG
  
  > In the Working Draft of 22 February 2007, Items 6a and 6b in section
  > 9.3.5, "The insert Action"
  > (http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert)  both
  > state that " If the cloned node is an attribute, then the target
  > location is before the first attribute of the insert location node
  > node."  Given the following, this directive is meaningless:
  > 
  > According to XML,
  > "the order of attribute specifications in a start-tag or empty-element
  > tag is not significant."
  > http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags
  > 
  > According to XML Infoset, the attributes property of the element
  > information item is "An unordered set of attribute information items,
  > one for each of the attributes"
  > http://www.w3.org/TR/xml-infoset/#infoitem.element
  > 
  > Also, according to the DOM, one cannot insert attributes at a given
  > location with insertBefore, appendChild, or replaceChild.  Therefore,
  > the only way to achieve the mandated effect would be to remove each of
  > the attributes, then set them again in the correct order.  However,
  > given the above, I'm not sure that would be reliable.
  > 
  > http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-1590626202
  > 
  > and
  > http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-952280727
  > 
  > 
  > -- 
  >   Paul Butcher, formsPlayer
  >   paul.butcher@x-port.net
  >   www.formsPlayer.com  standards. innovation.
  > 
  > 
  > 

1.11 <setvalue/> XPath evaluation context improvements

PROBLEM ID: 27

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response

NOTES:

  Not substantive in the "potentially objectionable" sense, just that we added a
  function that didn't exist before to solve the problem.

ORIGINAL MESSAGE:

  From: "Ivan Latysh" <IvanLatysh@yahoo.ca>
  
  
  Hello all,
  
     I want to propose a change to XForm spec regarding <setvalue/> "value"  
  attribute evaluation context.
     Currently spec force setvalue element to use target node context:
     [copy]
        "The evaluation context for this XPath expression is the result from  
  the Single Node Binding."
     [/copy]
     When in fact it should honour current scope and be consistent with other  
  XForms elements.
  
     I propose to update <setvalue/> "value" definition with:
     [copy]
     value
       Optional XPath expression to evaluate, with the result stored in the  
  selected instance data node.
       The evaluation context for this XPath expression described in 7.4  
  Evaluation Context.
     [/copy]
  
     Here is the real-world use-case that will work after the change:
       <xf:model id="myModel">
         <xf:instance id="myInstance" xmlns="">
           <root>
             <fruit>apple</fruit>
             <fruit>orange</fruit>
             <fruit>mandarine</fruit>
             <fruit>tomato</fruit>
             <bad-fruit>Unknown</bad-fruit>
           </root>
         </xf:instance>
       </xf:model>
       <xf:repeat nodeset="instance('myInstance')/fruit" model="myModel"  
  id="fruits-repeat">
         <xf:trigger>
           <xf:label>Pick</xf:label>
           <xf:action ev:event="DOMActivate">
             <xf:setvalue ref="instance('myInstance')/bad-fruit" value="."/>
           </xf:action>
         </xf:trigger>
       </xf:repeat>
  
     Taking into the consideration that such change may cause certain issues  
  with existing forms John M. Boyer propose to
     add a flag that will govern XForm behaviour:
     [John M. Boyer]
     I couldn't say what to name it, but maybe another attribute on the  
  default model would do the trick.  Something like
     unifiedcontext= "true|false".  The true setting would say that all  
  attributes of an element are evaluated with the
     in-scope evaluation context (i.e. the result of @context, if it appears,  
  or the default otherwise). The true setting
     could even be the default for 1.1, and the false setting could be the  
  default for 1.0 forms.
     [John M. Boyer]
  
     Also I belive that we can add the "version" attribute to <html/> tag.
     For example:
     <html xmlns="http://www.w3.org/1999/xhtml"  
  xmlns:xf="http://www.w3.org/2002/xforms"
      xmlns:ev="http://www.w3.org/2001/xml-events"  
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema" xf:version="1.1">
  
  
  -- 
  Best regards,
    Ivan                          mailto:IvanLatysh@yahoo.ca
  
  

FOLLOWUP 1:

  From: Mail Delivery Subsystem <MAILER-DAEMON@aptest.com>
  
  This is a MIME-encapsulated message
  
  --l5DHSOcp003364.1181756668/htmlwg.mn.aptest.com
  
      **********************************************
      **      THIS IS A WARNING MESSAGE ONLY      **
      **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
      **********************************************
  
  The original message was received at Wed, 13 Jun 2007 08:27:03 -0500
  from htmlwg.mn.aptest.com [127.0.0.1]
  
     ----- Transcript of session follows -----
  <IvanLatysh@yahoo.ca>... Deferred
  Warning: message still undelivered after 4 hours
  Will keep trying until message is 5 days old
  
  --l5DHSOcp003364.1181756668/htmlwg.mn.aptest.com
  Content-Type: message/delivery-status
  
  Reporting-MTA: dns; htmlwg.mn.aptest.com
  Arrival-Date: Wed, 13 Jun 2007 08:27:03 -0500
  
  Final-Recipient: RFC822; IvanLatysh@yahoo.ca
  Action: delayed
  Status: 4.4.2
  Last-Attempt-Date: Wed, 13 Jun 2007 12:44:28 -0500
  Will-Retry-Until: Mon, 18 Jun 2007 08:27:03 -0500
  
  --l5DHSOcp003364.1181756668/htmlwg.mn.aptest.com
  Content-Type: message/rfc822
  
  Return-Path: <xforms-issues@mn.aptest.com>
  Received: from localhost (htmlwg.mn.aptest.com [127.0.0.1])
  	by htmlwg.mn.aptest.com (8.13.1/8.13.1) with ESMTP id l5DDR3tX001710
  	for <IvanLatysh@yahoo.ca>; Wed, 13 Jun 2007 08:27:03 -0500
  Date: Wed, 13 Jun 2007 08:27:03 -0500
  Message-Id: <200706131327.l5DDR3tX001710@htmlwg.mn.aptest.com>
  From: xforms-issues@mn.aptest.com
  To: IvanLatysh@yahoo.ca
  Subject: Re: <setvalue/> XPath evaluation context improvements (PR#27)
  X-Loop: xforms-issues@mn.aptest.com
  
  Your issue has been added to the W3C's Forms Working Group Issue Tracking System.
  
  If you have further information about this issue to report, please reply to
  this message so that the additional data can be automatically attached to the
  original query.
  
  If you would like to check on the status of this issue, select the following
  link:
  
  http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues?findid=27     
  
  This link will take you to a page that shows your issue and its status.
  
  If you would like to check on the other issues in the
  system, you can do so via the web at http://htmlwg.mn.aptest.com/xforms-issues
  
  
  --l5DHSOcp003364.1181756668/htmlwg.mn.aptest.com--
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Ivan,
  
  thanks for reporting this. To solve this issue we decided to add a context()
  function to return the in-scope evaluation context for the element containing
  the attribute containing the xpath expression.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  > Hello all,
  > 
  >    I want to propose a change to XForm spec regarding <setvalue/> "value"  
  > attribute evaluation context.
  >    Currently spec force setvalue element to use target node context:
  >    [copy]
  >       "The evaluation context for this XPath expression is the result from  
  > the Single Node Binding."
  >    [/copy]
  >    When in fact it should honour current scope and be consistent with other  
  > XForms elements.
  > 
  >    I propose to update <setvalue/> "value" definition with:
  >    [copy]
  >    value
  >      Optional XPath expression to evaluate, with the result stored in the  
  > selected instance data node.
  >      The evaluation context for this XPath expression described in 7.4  
  > Evaluation Context.
  >    [/copy]
  > 
  >    Here is the real-world use-case that will work after the change:
  >      <xf:model id="myModel">
  >        <xf:instance id="myInstance" xmlns="">
  >          <root>
  >            <fruit>apple</fruit>
  >            <fruit>orange</fruit>
  >            <fruit>mandarine</fruit>
  >            <fruit>tomato</fruit>
  >            <bad-fruit>Unknown</bad-fruit>
  >          </root>
  >        </xf:instance>
  >      </xf:model>
  >      <xf:repeat nodeset="instance('myInstance')/fruit" model="myModel"  
  > id="fruits-repeat">
  >        <xf:trigger>
  >          <xf:label>Pick</xf:label>
  >          <xf:action ev:event="DOMActivate">
  >            <xf:setvalue ref="instance('myInstance')/bad-fruit" value="."/>
  >          </xf:action>
  >        </xf:trigger>
  >      </xf:repeat>
  > 
  >    Taking into the consideration that such change may cause certain issues  
  > with existing forms John M. Boyer propose to
  >    add a flag that will govern XForm behaviour:
  >    [John M. Boyer]
  >    I couldn't say what to name it, but maybe another attribute on the  
  > default model would do the trick.  Something like
  >    unifiedcontext= "true|false".  The true setting would say that all  
  > attributes of an element are evaluated with the
  >    in-scope evaluation context (i.e. the result of @context, if it appears,  
  > or the default otherwise). The true setting
  >    could even be the default for 1.1, and the false setting could be the  
  > default for 1.0 forms.
  >    [John M. Boyer]
  > 
  >    Also I belive that we can add the "version" attribute to <html/> tag.
  >    For example:
  >    <html xmlns="http://www.w3.org/1999/xhtml"  
  > xmlns:xf="http://www.w3.org/2002/xforms"
  >     xmlns:ev="http://www.w3.org/2001/xml-events"  
  > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  >     xmlns:xsd="http://www.w3.org/2001/XMLSchema" xf:version="1.1">
  > 
  > 
  > -- 
  > Best regards,
  >   Ivan                          mailto:IvanLatysh@yahoo.ca
  > 
  > 
  > 

1.12 Fw: [XForms 1.1] Inserting into an empty element (section 9.3.5 processing

PROBLEM ID: 172

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 006C3F4E88257329_=
  Content-Type: text/plain; charset="US-ASCII"
  
  ----- Forwarded by John Boyer/CanWest/IBM on 07/31/2007 12:42 PM -----
  
  "Clark, John" <CLARKJ2@ccf.org> 
  Sent by: www-forms-editor-request@w3.org
  07/20/2007 07:15 AM
  
  To
  www-forms-editor@w3.org
  cc
  
  Subject
  [XForms 1.1] Inserting into an empty element (section 9.3.5  processing 
  rule 6.a)
  
  
  
  
  
  
  
  As I read the latest working draft of the XForms specification[0], I am
  unsure what will happen at processing rule 6.a if the cloned node is not
  an attribute and the `insert location node` does not have any children.
  In this case, "the target location is before the first child of the
  insert location node", but that is not well-defined if there is no such
  first child.  I think it would be a significant gap in the specification
  if the eventual language would not allow a node to be inserted into an
  empty element.
  
  Is there any chance that this could be clarified (hopefully in favor of
  being able to insert a node into an element with no children)?
  
  [0] http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert
  
  Take care,
  
      John L. Clark  |  Systems Analyst
                     |  Cardio-Thoracic Surgery Research
   Cleveland Clinic  |  9500 Euclid Ave.   |  Cleveland, OH 44195
                     |  (216) 445-6011
  
  ===================================
  
  Cleveland Clinic is ranked one of the top hospitals
  in America by U.S. News & World Report (2007). 
  Visit us online at http://www.clevelandclinic.org for
  a complete listing of our services, staff and
  locations.
  
  
  Confidentiality Note:  This message is intended for use
  only by the individual or entity to which it is addressed
  and may contain information that is privileged,
  confidential, and exempt from disclosure under applicable
  law.  If the reader of this message is not the intended
  recipient or the employee or agent responsible for
  delivering the message to the intended recipient, you are
  hereby notified that any dissemination, distribution or
  copying of this communication is strictly prohibited.  If
  you have received this communication in error,  please
  contact the sender immediately and destroy the material in
  its entirety, whether electronic or hard copy.  Thank you.
  
  
  
  
  
  --=_alternative 006C3F4E88257329_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John
  Boyer/CanWest/IBM on 07/31/2007 12:42 PM -----</font>
  <br>
  <table width=100%>
  <tr valign=top>
  <td width=40%><font size=1 face="sans-serif"><b>&quot;Clark, John&quot;
  &lt;CLARKJ2@ccf.org&gt;</b> </font>
  <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font>
  <p><font size=1 face="sans-serif">07/20/2007 07:15 AM</font>
  <td width=59%>
  <table width=100%>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">To</font></div>
  <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">cc</font></div>
  <td>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">Subject</font></div>
  <td><font size=1 face="sans-serif">[XForms 1.1] Inserting into an empty
  element (section 9.3.5 &nbsp;processing rule 6.a)</font></table>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br>
  <br>
  <br><tt><font size=2><br>
  As I read the latest working draft of the XForms specification[0], I am<br>
  unsure what will happen at processing rule 6.a if the cloned node is not<br>
  an attribute and the `insert location node` does not have any children.<br>
  In this case, &quot;the target location is before the first child of the<br>
  insert location node&quot;, but that is not well-defined if there is no
  such<br>
  first child. &nbsp;I think it would be a significant gap in the specification<br>
  if the eventual language would not allow a node to be inserted into an<br>
  empty element.<br>
  <br>
  Is there any chance that this could be clarified (hopefully in favor of<br>
  being able to insert a node into an element with no children)?<br>
  <br>
  [0] </font></tt><a href="http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert"><tt><font size=2>http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert</font></tt></a><tt><font size=2><br>
  <br>
  Take care,<br>
  <br>
   &nbsp; &nbsp;John L. Clark &nbsp;| &nbsp;Systems Analyst<br>
   &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp;Cardio-Thoracic
  Surgery Research<br>
   Cleveland Clinic &nbsp;| &nbsp;9500 Euclid Ave. &nbsp; | &nbsp;Cleveland,
  OH 44195<br>
   &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp;(216)
  445-6011<br>
  <br>
  ===================================<br>
  <br>
  Cleveland Clinic is ranked one of the top hospitals<br>
  in America by U.S. News &amp; World Report (2007). &nbsp;<br>
  Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2>
  for<br>
  a complete listing of our services, staff and<br>
  locations.<br>
  <br>
  <br>
  Confidentiality Note: &nbsp;This message is intended for use<br>
  only by the individual or entity to which it is addressed<br>
  and may contain information that is privileged,<br>
  confidential, and exempt from disclosure under applicable<br>
  law. &nbsp;If the reader of this message is not the intended<br>
  recipient or the employee or agent responsible for<br>
  delivering the message to the intended recipient, you are<br>
  hereby notified that any dissemination, distribution or<br>
  copying of this communication is strictly prohibited. &nbsp;If<br>
  you have received this communication in error, &nbsp;please<br>
  contact the sender immediately and destroy the material in<br>
  its entirety, whether electronic or hard copy. &nbsp;Thank you.<br>
  <br>
  <br>
  <br>
  <br>
  </font></tt>
  --=_alternative 006C3F4E88257329_=--
  

FOLLOWUP 1:

  From: John Boyer <xforms-issues@aptest.com>
  
  Hi John,
  
  Yes, it was an omission of the spec, and insertion into an empty node was
  intended.
  The latest editor's draft available from the Forms WG home page contains a
  correction.  Please see the diff-marked version.  Also, please note that step 6
  received other modifications due to addressing other last call comments, so the
  fix needed to address your specific issue is at the end of step 6c.  Please let
  us know if you have any further concerns about this issue.
  
  Thanks,
  John Boyer
  
  > Subject
  > [XForms 1.1] Inserting into an empty element (section 9.3.5  processing 
  > rule 6.a)
  > 
  > As I read the latest working draft of the XForms specification[0], I am
  > unsure what will happen at processing rule 6.a if the cloned node is not
  > an attribute and the `insert location node` does not have any children.
  > In this case, "the target location is before the first child of the
  > insert location node", but that is not well-defined if there is no such
  > first child.  I think it would be a significant gap in the specification
  > if the eventual language would not allow a node to be inserted into an
  > empty element.
  > 
  > Is there any chance that this could be clarified (hopefully in favor of
  > being able to insert a node into an element with no children)?
  > 
  > [0] http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert
  > 
  > Take care,
  > 
  >     John L. Clark  |  Systems Analyst
  >                    |  Cardio-Thoracic Surgery Research
  >  Cleveland Clinic  |  9500 Euclid Ave.   |  Cleveland, OH 44195
  >                    |  (216) 445-6011
  > 
  > ===================================
  > 
  > Cleveland Clinic is ranked one of the top hospitals
  > in America by U.S. News & World Report (2007). 
  > Visit us online at http://www.clevelandclinic.org for
  > a complete listing of our services, staff and
  > locations.
  > 
  > 
  > Confidentiality Note:  This message is intended for use
  > only by the individual or entity to which it is addressed
  > and may contain information that is privileged,
  > confidential, and exempt from disclosure under applicable
  > law.  If the reader of this message is not the intended
  > recipient or the employee or agent responsible for
  > delivering the message to the intended recipient, you are
  > hereby notified that any dissemination, distribution or
  > copying of this communication is strictly prohibited.  If
  > you have received this communication in error,  please
  > contact the sender immediately and destroy the material in
  > its entirety, whether electronic or hard copy.  Thank you.
  > 
  > 
  > 
  > 
  > 
  > --=_alternative 006C3F4E88257329_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John
  > Boyer/CanWest/IBM on 07/31/2007 12:42 PM -----</font>
  > <br>
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John"
  > <CLARKJ2@ccf.org></b> </font>
  > <br><font size=1 face="sans-serif">Sent by:
  > www-forms-editor-request@w3.org</font>
  > <p><font size=1 face="sans-serif">07/20/2007 07:15 AM</font>
  > <td width=59%>
  > <table width=100%>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">To</font></div>
  > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">cc</font></div>
  > <td>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">Subject</font></div>
  > <td><font size=1 face="sans-serif">[XForms 1.1] Inserting into an empty
  > element (section 9.3.5  processing rule 6.a)</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><tt><font size=2><br>
  > As I read the latest working draft of the XForms specification[0], I am<br>
  > unsure what will happen at processing rule 6.a if the cloned node is not<br>
  > an attribute and the `insert location node` does not have any children.<br>
  > In this case, "the target location is before the first child of the<br>
  > insert location node", but that is not well-defined if there is no
  > such<br>
  > first child.  I think it would be a significant gap in the
  > specification<br>
  > if the eventual language would not allow a node to be inserted into an<br>
  > empty element.<br>
  > <br>
  > Is there any chance that this could be clarified (hopefully in favor of<br>
  > being able to insert a node into an element with no children)?<br>
  > <br>
  > [0] </font></tt><a
  href="http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert"><tt><font
  > size=2>http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert</font></tt></a><tt><font
  > size=2><br>
  > <br>
  > Take care,<br>
  > <br>
  >     John L. Clark  |  Systems Analyst<br>
  >                    |
  >  Cardio-Thoracic
  > Surgery Research<br>
  >  Cleveland Clinic  |  9500 Euclid Ave.   |  Cleveland,
  > OH 44195<br>
  >                    |  (216)
  > 445-6011<br>
  > <br>
  > ===================================<br>
  > <br>
  > Cleveland Clinic is ranked one of the top hospitals<br>
  > in America by U.S. News & World Report (2007).  <br>
  > Visit us online at </font></tt><a
  href=http://www.clevelandclinic.org/><tt><font
  > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2>
  > for<br>
  > a complete listing of our services, staff and<br>
  > locations.<br>
  > <br>
  > <br>
  > Confidentiality Note:  This message is intended for use<br>
  > only by the individual or entity to which it is addressed<br>
  > and may contain information that is privileged,<br>
  > confidential, and exempt from disclosure under applicable<br>
  > law.  If the reader of this message is not the intended<br>
  > recipient or the employee or agent responsible for<br>
  > delivering the message to the intended recipient, you are<br>
  > hereby notified that any dissemination, distribution or<br>
  > copying of this communication is strictly prohibited.  If<br>
  > you have received this communication in error,  please<br>
  > contact the sender immediately and destroy the material in<br>
  > its entirety, whether electronic or hard copy.  Thank you.<br>
  > <br>
  > <br>
  > <br>
  > <br>
  > </font></tt>
  > --=_alternative 006C3F4E88257329_=--
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi John,
  
  Yes, it was an omission of the spec, and insertion into an empty node was
  intended.
  The latest editor's draft available from the Forms WG home page contains a
  correction.  Please see the diff-marked version.  Also, please note that step 6
  received other modifications due to addressing other last call comments, so the
  fix needed to address your specific issue is at the end of step 6c.  Please let
  us know if you have any further concerns about this issue.
  
  Thanks,
  John Boyer
  
  > Subject
  > [XForms 1.1] Inserting into an empty element (section 9.3.5  processing 
  > rule 6.a)
  > 
  > As I read the latest working draft of the XForms specification[0], I am
  > unsure what will happen at processing rule 6.a if the cloned node is not
  > an attribute and the `insert location node` does not have any children.
  > In this case, "the target location is before the first child of the
  > insert location node", but that is not well-defined if there is no such
  > first child.  I think it would be a significant gap in the specification
  > if the eventual language would not allow a node to be inserted into an
  > empty element.
  > 
  > Is there any chance that this could be clarified (hopefully in favor of
  > being able to insert a node into an element with no children)?
  > 
  > [0] http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert
  > 
  > Take care,
  > 
  >     John L. Clark  |  Systems Analyst
  >                    |  Cardio-Thoracic Surgery Research
  >  Cleveland Clinic  |  9500 Euclid Ave.   |  Cleveland, OH 44195
  >                    |  (216) 445-6011
  > 
  > ===================================
  > 
  > Cleveland Clinic is ranked one of the top hospitals
  > in America by U.S. News & World Report (2007). 
  > Visit us online at http://www.clevelandclinic.org for
  > a complete listing of our services, staff and
  > locations.
  > 
  > 
  > Confidentiality Note:  This message is intended for use
  > only by the individual or entity to which it is addressed
  > and may contain information that is privileged,
  > confidential, and exempt from disclosure under applicable
  > law.  If the reader of this message is not the intended
  > recipient or the employee or agent responsible for
  > delivering the message to the intended recipient, you are
  > hereby notified that any dissemination, distribution or
  > copying of this communication is strictly prohibited.  If
  > you have received this communication in error,  please
  > contact the sender immediately and destroy the material in
  > its entirety, whether electronic or hard copy.  Thank you.
  > 
  > 
  > 
  > 
  > 
  > --=_alternative 006C3F4E88257329_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John
  > Boyer/CanWest/IBM on 07/31/2007 12:42 PM -----</font>
  > <br>
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John"
  > <CLARKJ2@ccf.org></b> </font>
  > <br><font size=1 face="sans-serif">Sent by:
  > www-forms-editor-request@w3.org</font>
  > <p><font size=1 face="sans-serif">07/20/2007 07:15 AM</font>
  > <td width=59%>
  > <table width=100%>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">To</font></div>
  > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">cc</font></div>
  > <td>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">Subject</font></div>
  > <td><font size=1 face="sans-serif">[XForms 1.1] Inserting into an empty
  > element (section 9.3.5  processing rule 6.a)</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><tt><font size=2><br>
  > As I read the latest working draft of the XForms specification[0], I am<br>
  > unsure what will happen at processing rule 6.a if the cloned node is not<br>
  > an attribute and the `insert location node` does not have any children.<br>
  > In this case, "the target location is before the first child of the<br>
  > insert location node", but that is not well-defined if there is no
  > such<br>
  > first child.  I think it would be a significant gap in the
  > specification<br>
  > if the eventual language would not allow a node to be inserted into an<br>
  > empty element.<br>
  > <br>
  > Is there any chance that this could be clarified (hopefully in favor of<br>
  > being able to insert a node into an element with no children)?<br>
  > <br>
  > [0] </font></tt><a
  href="http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert"><tt><font
  > size=2>http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert</font></tt></a><tt><font
  > size=2><br>
  > <br>
  > Take care,<br>
  > <br>
  >     John L. Clark  |  Systems Analyst<br>
  >                    |
  >  Cardio-Thoracic
  > Surgery Research<br>
  >  Cleveland Clinic  |  9500 Euclid Ave.   |  Cleveland,
  > OH 44195<br>
  >                    |  (216)
  > 445-6011<br>
  > <br>
  > ===================================<br>
  > <br>
  > Cleveland Clinic is ranked one of the top hospitals<br>
  > in America by U.S. News & World Report (2007).  <br>
  > Visit us online at </font></tt><a
  href=http://www.clevelandclinic.org/><tt><font
  > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2>
  > for<br>
  > a complete listing of our services, staff and<br>
  > locations.<br>
  > <br>
  > <br>
  > Confidentiality Note:  This message is intended for use<br>
  > only by the individual or entity to which it is addressed<br>
  > and may contain information that is privileged,<br>
  > confidential, and exempt from disclosure under applicable<br>
  > law.  If the reader of this message is not the intended<br>
  > recipient or the employee or agent responsible for<br>
  > delivering the message to the intended recipient, you are<br>
  > hereby notified that any dissemination, distribution or<br>
  > copying of this communication is strictly prohibited.  If<br>
  > you have received this communication in error,  please<br>
  > contact the sender immediately and destroy the material in<br>
  > its entirety, whether electronic or hard copy.  Thank you.<br>
  > <br>
  > <br>
  > <br>
  > <br>
  > </font></tt>
  > --=_alternative 006C3F4E88257329_=--
  > 
  > 

REPLY 2:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi John,
  Yes, it was an omission of the spec, and insertion into an empty node was
  intended.
  
  The latest editor's draft available from the Forms WG home page contains a
  correction.  Please see the diff-marked version.  Also, please note that step 6
  received other modifications due to addressing other last call comments, so the
  fix needed to address your specific issue is at the end of step 6c.  Please let
  us know if you have any further concerns about this issue.
  
  Thanks,
  John Boyer
  
  > This is a multipart message in MIME format.
  > --=_alternative 006C3F4E88257329_=
  > Content-Type: text/plain; charset="US-ASCII"
  > 
  > ----- Forwarded by John Boyer/CanWest/IBM on 07/31/2007 12:42 PM -----
  > 
  > "Clark, John" <CLARKJ2@ccf.org> 
  > Sent by: www-forms-editor-request@w3.org
  > 07/20/2007 07:15 AM
  > 
  > To
  > www-forms-editor@w3.org
  > cc
  > 
  > Subject
  > [XForms 1.1] Inserting into an empty element (section 9.3.5  processing 
  > rule 6.a)
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > As I read the latest working draft of the XForms specification[0], I am
  > unsure what will happen at processing rule 6.a if the cloned node is not
  > an attribute and the `insert location node` does not have any children.
  > In this case, "the target location is before the first child of the
  > insert location node", but that is not well-defined if there is no such
  > first child.  I think it would be a significant gap in the specification
  > if the eventual language would not allow a node to be inserted into an
  > empty element.
  > 
  > Is there any chance that this could be clarified (hopefully in favor of
  > being able to insert a node into an element with no children)?
  > 
  > [0] http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert
  > 
  > Take care,
  > 
  >     John L. Clark  |  Systems Analyst
  >                    |  Cardio-Thoracic Surgery Research
  >  Cleveland Clinic  |  9500 Euclid Ave.   |  Cleveland, OH 44195
  >                    |  (216) 445-6011
  > 
  > ===================================
  > 
  > Cleveland Clinic is ranked one of the top hospitals
  > in America by U.S. News & World Report (2007). 
  > Visit us online at http://www.clevelandclinic.org for
  > a complete listing of our services, staff and
  > locations.
  > 
  > 
  > Confidentiality Note:  This message is intended for use
  > only by the individual or entity to which it is addressed
  > and may contain information that is privileged,
  > confidential, and exempt from disclosure under applicable
  > law.  If the reader of this message is not the intended
  > recipient or the employee or agent responsible for
  > delivering the message to the intended recipient, you are
  > hereby notified that any dissemination, distribution or
  > copying of this communication is strictly prohibited.  If
  > you have received this communication in error,  please
  > contact the sender immediately and destroy the material in
  > its entirety, whether electronic or hard copy.  Thank you.
  > 
  > 
  > 
  > 
  > 
  > --=_alternative 006C3F4E88257329_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John
  > Boyer/CanWest/IBM on 07/31/2007 12:42 PM -----</font>
  > <br>
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John"
  > <CLARKJ2@ccf.org></b> </font>
  > <br><font size=1 face="sans-serif">Sent by:
  > www-forms-editor-request@w3.org</font>
  > <p><font size=1 face="sans-serif">07/20/2007 07:15 AM</font>
  > <td width=59%>
  > <table width=100%>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">To</font></div>
  > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">cc</font></div>
  > <td>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">Subject</font></div>
  > <td><font size=1 face="sans-serif">[XForms 1.1] Inserting into an empty
  > element (section 9.3.5  processing rule 6.a)</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><tt><font size=2><br>
  > As I read the latest working draft of the XForms specification[0], I am<br>
  > unsure what will happen at processing rule 6.a if the cloned node is not<br>
  > an attribute and the `insert location node` does not have any children.<br>
  > In this case, "the target location is before the first child of the<br>
  > insert location node", but that is not well-defined if there is no
  > such<br>
  > first child.  I think it would be a significant gap in the
  > specification<br>
  > if the eventual language would not allow a node to be inserted into an<br>
  > empty element.<br>
  > <br>
  > Is there any chance that this could be clarified (hopefully in favor of<br>
  > being able to insert a node into an element with no children)?<br>
  > <br>
  > [0] </font></tt><a
  href="http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert"><tt><font
  > size=2>http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert</font></tt></a><tt><font
  > size=2><br>
  > <br>
  > Take care,<br>
  > <br>
  >     John L. Clark  |  Systems Analyst<br>
  >                    |
  >  Cardio-Thoracic
  > Surgery Research<br>
  >  Cleveland Clinic  |  9500 Euclid Ave.   |  Cleveland,
  > OH 44195<br>
  >                    |  (216)
  > 445-6011<br>
  > <br>
  > ===================================<br>
  > <br>
  > Cleveland Clinic is ranked one of the top hospitals<br>
  > in America by U.S. News & World Report (2007).  <br>
  > Visit us online at </font></tt><a
  href=http://www.clevelandclinic.org/><tt><font
  > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2>
  > for<br>
  > a complete listing of our services, staff and<br>
  > locations.<br>
  > <br>
  > <br>
  > Confidentiality Note:  This message is intended for use<br>
  > only by the individual or entity to which it is addressed<br>
  > and may contain information that is privileged,<br>
  > confidential, and exempt from disclosure under applicable<br>
  > law.  If the reader of this message is not the intended<br>
  > recipient or the employee or agent responsible for<br>
  > delivering the message to the intended recipient, you are<br>
  > hereby notified that any dissemination, distribution or<br>
  > copying of this communication is strictly prohibited.  If<br>
  > you have received this communication in error,  please<br>
  > contact the sender immediately and destroy the material in<br>
  > its entirety, whether electronic or hard copy.  Thank you.<br>
  > <br>
  > <br>
  > <br>
  > <br>
  > </font></tt>
  > --=_alternative 006C3F4E88257329_=--
  > 
  > 

2. Appendices

2.1 example "G.1 XForms in XHTML"

PROBLEM ID: 122

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  We will simplify

ORIGINAL MESSAGE:

  From: "Yves Savourel" <ysavourel@translate.com>
  
  --- 4) The example "G.1 XForms in XHTML" is actually something usually  
  frown upon in localization: Having a source file in multiple
  languages.
  
  Such files are very difficult to process in a normal localization  
  workflow. For example if you had to translate the file in German
  you would have to add HTML and XForm code rather than just take the  
  English source and translate it. Also if you have the file to
  translate into several languages, you have to use different translator and  
  re-consolidate the file after all are done (rather than
  translate in parallel.
  
  I realize this is just an example meant to illustrate many of XForm  
  features, but if the same goal could be achieved in a
  monolingual file (not necessarily English) it would be much better from  
  the perspective of internationalization.
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thanks for this comment.
  
  On reviewing the example, we decided it was too complicated to be useful at this
  point, so we will replace it with a simpler example, that doesn't use
  multilingual text.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  > --- 4) The example "G.1 XForms in XHTML" is actually something usually  
  > frown upon in localization: Having a source file in multiple
  > languages.
  > 
  > Such files are very difficult to process in a normal localization  
  > workflow. For example if you had to translate the file in German
  > you would have to add HTML and XForm code rather than just take the  
  > English source and translate it. Also if you have the file to
  > translate into several languages, you have to use different translator and  
  > re-consolidate the file after all are done (rather than
  > translate in parallel.
  > 
  > I realize this is just an example meant to illustrate many of XForm  
  > features, but if the same goal could be achieved in a
  > monolingual file (not necessarily English) it would be much better from  
  > the perspective of internationalization.
  > 
  > 

2.2 CDF06 - 13 Glossary of Terms missing compound document.

PROBLEM ID: 128

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com>
  
  
  Add
  "Compound Document
         [Definition: A [CDRF 1.0] Compound Document is a document that
         combines mutliple document formats either by reference, by inclusion
         or both.]"
  

FOLLOWUP 1:

  From: member-cdf-request@w3.org
  
  *** NOTE: ***
  
      Your message was sent from an address which is not on the list
      of people who are authorized to post to this mailing list.
      Therefore, your message has been forwarded to the list maintainer
      for manual processing.
  
      If you do not see your message appear on the list or in the
      mailing list archives within a few business days, you may wish
      to contact the mailing list maintainer to investigate the delay.
  
      -- W3C Postmaster
         http://www.w3.org/Mail/
  
  your message follows:
  ----------------------------------------------------------------------------
  
  
  Hi Kevin,
  
  The Forms WG agreed to add the definition as given below.
  It now appears in the editor's draft available from the working group web site.
  
  Best regards,
  John Boyer
  
  > 
  > Add
  > "Compound Document
  >        [Definition: A [CDRF 1.0] Compound Document is a document that
  >        combines mutliple document formats either by reference, by inclusion
  >        or both.]"
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Kevin,
  
  The Forms WG agreed to add the definition as given below.
  It now appears in the editor's draft available from the working group web site.
  
  Best regards,
  John Boyer
  
  > 
  > Add
  > "Compound Document
  >        [Definition: A [CDRF 1.0] Compound Document is a document that
  >        combines mutliple document formats either by reference, by inclusion
  >        or both.]"
  > 
  > 

2.3 example "G.3 Survey Using XForms and SVG

PROBLEM ID: 120

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  It should have been "latte" anyway (it's Italian not French)

ORIGINAL MESSAGE:

  From: "Yves Savourel" <ysavourel@translate.com>
  
  --- 2) In the example "G.3 Survey Using XForms and SVG"
  
  The 'é' in the different occurrences of 'latté' displays as a block in IE7  
  and as a '?' in FireFox. I'm guessing the HTML file is
  not in the encoding it declares.
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thanks for your comment. We have now fixed this.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  > --- 2) In the example "G.3 Survey Using XForms and SVG"
  > 
  > The '�' in the different occurrences of 'latt�' displays as a block in IE7
   
  > and as a '?' in FireFox. I'm guessing the HTML file is
  > not in the encoding it declares.
  > 
  > 

REPLY 2:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thanks for your comment. We have now fixed this.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  > --- 2) In the example "G.3 Survey Using XForms and SVG"
  > 
  > The '�' in the different occurrences of 'latt�' displays as a block in IE7
   
  > and as a '?' in FireFox. I'm guessing the HTML file is
  > not in the encoding it declares.
  > 
  > 

2.4 Add scripts to XForms input-mode script list in Appendix E

PROBLEM ID: 106

STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: None

NOTES:

  This issue is deferred because the information is informative, so it can be
  added after the CR transition.  There is no reason to hold up advancement while
  waiting for this non-normative information.
  
  This is a duplicate of issue PR #14 (and a few others)
  
  Suggest replacing list by reference to specs.
  
  Waiting for MD's opinion, and hopefully text.
  
  Martin replied: 
  http://lists.w3.org/Archives/Public/www-forms-editor/2007Jun/0065
  <<<<
  This may make sense to some extent, but it's not totally clear that
  all future additions to the Unicode list of scripts can be just added
  to the list of input mode tags in XForms. It is certainly not the case
  that the current list of scripts in Unicode is identical with the
  (currently proposed, incl. below) list of tags in XForms.
  
  Also, because there are changes in spelling, I think it's much
  more useful for implementers and users to have a full list.
  What I could immagine is that we add a sentence saying something
  like "it is expected that future versions of this specification
  will include tokens for scripts added to Unicode wherever that
  makes sense".
  >>>>

ORIGINAL MESSAGE:

  From: "Martin Duerst" <duerst@it.aoyama.ac.jp>
  
  
  Dear XForms Editors,
  
  This is a Last Call Comment on http://www.w3.org/TR/xforms11/.
  
  Appendix E of this specification (http://www.w3.org/TR/xforms11/#mode),
  entitled "Input Modes", should be updated to be in sync with the most
  recent list of scripts from Unicode/ISO 10646.
  
  A rough count (using the Unix 'wc' utilty) showed that about 15
  scripts are missing from the list of tokens at
  http://www.w3.org/TR/xforms11/#mode-values.
  
  A point-by-point comparison with
  http://www.unicode.org/Public/5.0.0/ucd/PropertyValueAliases.txt
  (look below the line "# Script (sc)") gave the following list
  (more than 15 because E.3.1 contains quite a few special values):
  (starting with lowercase and converting spaces to camelcase in
  line with the currently available tokens (e.g. canaidianAboriginal)).
  
  balinese
  buginese
  coptic
  cypriot
  glagolitic
  kharoshthi
  limbu
  linearB
  nko
  osmanya
  phagsPa
  phoenician
  shavian
  sylotiNagri
  taiLe
  newTaiLue
  tifinagh
  ugaritic
  oldPersian
  cuneiform
  
  This list of tokens can be included as is (with "Unicode script name"
  in the Comments column), but should be cross-checked to make sure
  I didn't miss anything. The text above the table can then be updated
  to say "The version of the Unicode Standard that these script name
  are taken from is 5.0." instead of "The version of the Unicode Standard
  that these script names are taken from is 3.2.".
  
  Many of the scripts (e.g. Cunieform) are not necessarily what you
  would expect as your typical XForms input, but some of the tokens
  already available in XForms 1.0 also don't have a high probability
  of usage, and it's better to be complete than to leave something out
  that later may be needed.
  
  Some people may raise the concern that adding these script tokens
  will force the spec to go to Last Call again. While this would be
  true for any genuinely new feature being added after Last Call,
  it is difficult to see why a new Last Call would be needed just
  because the list of scripts is being completed. No XForms implementation
  is forced to support all of these values anyway, but not including
  a value that's currently not supported would create a weird
  chicken-and-egg problem.
  
  Regards,      Martin.
  
  
  #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
  #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp
  

FOLLOWUP 1:

  From: public-i18n-core-request@w3.org
  
  *** NOTE: ***
  
      Your message was sent from an address which is not on the list
      of people who are authorized to post to this mailing list.
      Therefore, your message has been forwarded to the list maintainer
      for manual processing.
  
      If you do not see your message appear on the list or in the
      mailing list archives within a few business days, you may wish
      to contact the mailing list maintainer to investigate the delay.
  
      -- W3C Postmaster
         http://www.w3.org/Mail/
  
  your message follows:
  ----------------------------------------------------------------------------
  
  
  Martin,
  
  I wonder if it woudn't be more efficient to have this list by reference rather
  than by inclusion.
  
  Since you are the author of this section, would you be willing to suggest the
  text to replace the list with references to the normative specs?
  
  Best wishes,
  
  Steven Pemberton
  
  > Appendix E of this specification (http://www.w3.org/TR/xforms11/#mode),
  > entitled "Input Modes", should be updated to be in sync with the most
  > recent list of scripts from Unicode/ISO 10646.
  > 
  > A rough count (using the Unix 'wc' utilty) showed that about 15
  > scripts are missing from the list of tokens at
  > http://www.w3.org/TR/xforms11/#mode-values.
  > 
  > A point-by-point comparison with
  > http://www.unicode.org/Public/5.0.0/ucd/PropertyValueAliases.txt
  > (look below the line "# Script (sc)") gave the following list
  > (more than 15 because E.3.1 contains quite a few special values):
  > (starting with lowercase and converting spaces to camelcase in
  > line with the currently available tokens (e.g. canaidianAboriginal)).
  > 
  > balinese
  > buginese
  > coptic
  > cypriot
  > glagolitic
  > kharoshthi
  > limbu
  > linearB
  > nko
  > osmanya
  > phagsPa
  > phoenician
  > shavian
  > sylotiNagri
  > taiLe
  > newTaiLue
  > tifinagh
  > ugaritic
  > oldPersian
  > cuneiform
  > 
  > This list of tokens can be included as is (with "Unicode script name"
  > in the Comments column), but should be cross-checked to make sure
  > I didn't miss anything. The text above the table can then be updated
  > to say "The version of the Unicode Standard that these script name
  > are taken from is 5.0." instead of "The version of the Unicode Standard
  > that these script names are taken from is 3.2.".
  > 
  > Many of the scripts (e.g. Cunieform) are not necessarily what you
  > would expect as your typical XForms input, but some of the tokens
  > already available in XForms 1.0 also don't have a high probability
  > of usage, and it's better to be complete than to leave something out
  > that later may be needed.
  > 
  > Some people may raise the concern that adding these script tokens
  > will force the spec to go to Last Call again. While this would be
  > true for any genuinely new feature being added after Last Call,
  > it is difficult to see why a new Last Call would be needed just
  > because the list of scripts is being completed. No XForms implementation
  > is forced to support all of these values anyway, but not including
  > a value that's currently not supported would create a weird
  > chicken-and-egg problem.
  > 
  > Regards,      Martin.
  > 
  > 
  > #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
  > #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp
  > 
  > 
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Martin,
  
  I wonder if it woudn't be more efficient to have this list by reference rather
  than by inclusion.
  
  Since you are the author of this section, would you be willing to suggest the
  text to replace the list with references to the normative specs?
  
  Best wishes,
  
  Steven Pemberton
  
  > Appendix E of this specification (http://www.w3.org/TR/xforms11/#mode),
  > entitled "Input Modes", should be updated to be in sync with the most
  > recent list of scripts from Unicode/ISO 10646.
  > 
  > A rough count (using the Unix 'wc' utilty) showed that about 15
  > scripts are missing from the list of tokens at
  > http://www.w3.org/TR/xforms11/#mode-values.
  > 
  > A point-by-point comparison with
  > http://www.unicode.org/Public/5.0.0/ucd/PropertyValueAliases.txt
  > (look below the line "# Script (sc)") gave the following list
  > (more than 15 because E.3.1 contains quite a few special values):
  > (starting with lowercase and converting spaces to camelcase in
  > line with the currently available tokens (e.g. canaidianAboriginal)).
  > 
  > balinese
  > buginese
  > coptic
  > cypriot
  > glagolitic
  > kharoshthi
  > limbu
  > linearB
  > nko
  > osmanya
  > phagsPa
  > phoenician
  > shavian
  > sylotiNagri
  > taiLe
  > newTaiLue
  > tifinagh
  > ugaritic
  > oldPersian
  > cuneiform
  > 
  > This list of tokens can be included as is (with "Unicode script name"
  > in the Comments column), but should be cross-checked to make sure
  > I didn't miss anything. The text above the table can then be updated
  > to say "The version of the Unicode Standard that these script name
  > are taken from is 5.0." instead of "The version of the Unicode Standard
  > that these script names are taken from is 3.2.".
  > 
  > Many of the scripts (e.g. Cunieform) are not necessarily what you
  > would expect as your typical XForms input, but some of the tokens
  > already available in XForms 1.0 also don't have a high probability
  > of usage, and it's better to be complete than to leave something out
  > that later may be needed.
  > 
  > Some people may raise the concern that adding these script tokens
  > will force the spec to go to Last Call again. While this would be
  > true for any genuinely new feature being added after Last Call,
  > it is difficult to see why a new Last Call would be needed just
  > because the list of scripts is being completed. No XForms implementation
  > is forced to support all of these values anyway, but not including
  > a value that's currently not supported would create a weird
  > chicken-and-egg problem.
  > 
  > Regards,      Martin.
  > 
  > 
  > #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
  > #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp
  > 
  > 

REPLY 2:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Martin,
  
  As we previously indicated to you, we noticed that the appendix was not marked
  informative, which was an error we have now corrected.
  
  We have deferred this issue for the CR transition because the appendix is
  informative.  
  
  We would like to have your help in producing an update to this appendix which
  you previously wrote.  Ideally, it would not contain another set of long lists,
  but rather would reference the appropriate technical specifications that contain
  those lists, and make some indication that documents which supercede those
  technical specifications may be used.  This will allow people to add more script
  tokens over time as the relevant technical specifications are updated, without
  having to also update the XForms recommendation.
  
  Best regards,
  John Boyer
  
  > 
  > Dear XForms Editors,
  > 
  > This is a Last Call Comment on http://www.w3.org/TR/xforms11/.
  > 
  > Appendix E of this specification (http://www.w3.org/TR/xforms11/#mode),
  > entitled "Input Modes", should be updated to be in sync with the most
  > recent list of scripts from Unicode/ISO 10646.
  > 
  > A rough count (using the Unix 'wc' utilty) showed that about 15
  > scripts are missing from the list of tokens at
  > http://www.w3.org/TR/xforms11/#mode-values.
  > 
  > A point-by-point comparison with
  > http://www.unicode.org/Public/5.0.0/ucd/PropertyValueAliases.txt
  > (look below the line "# Script (sc)") gave the following list
  > (more than 15 because E.3.1 contains quite a few special values):
  > (starting with lowercase and converting spaces to camelcase in
  > line with the currently available tokens (e.g. canaidianAboriginal)).
  > 
  > balinese
  > buginese
  > coptic
  > cypriot
  > glagolitic
  > kharoshthi
  > limbu
  > linearB
  > nko
  > osmanya
  > phagsPa
  > phoenician
  > shavian
  > sylotiNagri
  > taiLe
  > newTaiLue
  > tifinagh
  > ugaritic
  > oldPersian
  > cuneiform
  > 
  > This list of tokens can be included as is (with "Unicode script name"
  > in the Comments column), but should be cross-checked to make sure
  > I didn't miss anything. The text above the table can then be updated
  > to say "The version of the Unicode Standard that these script name
  > are taken from is 5.0." instead of "The version of the Unicode Standard
  > that these script names are taken from is 3.2.".
  > 
  > Many of the scripts (e.g. Cunieform) are not necessarily what you
  > would expect as your typical XForms input, but some of the tokens
  > already available in XForms 1.0 also don't have a high probability
  > of usage, and it's better to be complete than to leave something out
  > that later may be needed.
  > 
  > Some people may raise the concern that adding these script tokens
  > will force the spec to go to Last Call again. While this would be
  > true for any genuinely new feature being added after Last Call,
  > it is difficult to see why a new Last Call would be needed just
  > because the list of scripts is being completed. No XForms implementation
  > is forced to support all of these values anyway, but not including
  > a value that's currently not supported would create a weird
  > chicken-and-egg problem.
  > 
  > Regards,      Martin.
  > 
  > 
  > #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
  > #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp
  > 
  > 

2.5 E.3.1 Script Tokens

PROBLEM ID: 121

STATE: Approved and Implemented
EDIT: N/A
RESOLUTION: Accept
USER POSITION: Agree

NOTES:

  Yes, we are doing this in collaboration with M Duerst.
  This is a duplicate of 106.

ORIGINAL MESSAGE:

  From: "Yves Savourel" <ysavourel@translate.com>
  
  --- 3) The section "E.3.1 Script Tokens" lists possible values for  
  inputMode. It says the values have been taken from Unicode 3.2.
  Maybe it's worth checking it against the latest version of Unicode (5.0  
  now) and make addition as needed? [Just a suggestion]
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Yes, we quite agree, and we are collaborating with Martin Duerst (the author of
  this section) to ensure that the list is correct.
  
  Thanks for the comment.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  > --- 3) The section "E.3.1 Script Tokens" lists possible values for  
  > inputMode. It says the values have been taken from Unicode 3.2.
  > Maybe it's worth checking it against the latest version of Unicode (5.0  
  > now) and make addition as needed? [Just a suggestion]
  > 
  > 

3. Conformance

3.1 Last Call Comment: XForms 1.1 refers normatively to XForms 1.0 requirements but not XForms 1.1 requirements

PROBLEM ID: 49

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
  
  
  This may be a simple editing error, but the XForms 1.1 Working Draft [1]
  in the Normative References section [2] refers via [3] to XForms 1.0
  Requirements [4] but does not cite XForms 1.1 Requirements [5].
  
  [1] http://www.w3.org/TR/2007/WD-xforms11-20070222/
  [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req
  [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm
  [4] http://www.w3.org/TR/xhtml-forms-req
  [5] http://www.w3.org/TR/xforms-11-req/
  
  
  Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1
  requirements?
  
  
  Leigh L. Klotz, Jr.
  Xerox Corporation
  

FOLLOWUP 1:

  From: w3c-forms-request@w3.org
  
  *** NOTE: ***
  
      Your message was sent from an address which is not on the list
      of people who are authorized to post to this mailing list.
      Therefore, your message has been forwarded to the list maintainer
      for manual processing.
  
      If you do not see your message appear on the list or in the
      mailing list archives within a few business days, you may wish
      to contact the mailing list maintainer to investigate the delay.
  
      -- W3C Postmaster
         http://www.w3.org/Mail/
  
  your message follows:
  ----------------------------------------------------------------------------
  
  
  > This may be a simple editing error, but the XForms 1.1 Working Draft [1]
  > in the Normative References section [2] refers via [3] to XForms 1.0
  > Requirements [4] but does not cite XForms 1.1 Requirements [5].
  > 
  > [1] http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req
  > [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm
  > [4] http://www.w3.org/TR/xhtml-forms-req
  > [5] http://www.w3.org/TR/xforms-11-req/
  > 
  > 
  > Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1
  > requirements?
  > 
  > 
  
  We removed the XForms 1.0 requirements and do not add XForms 1.1.
  
  > Leigh L. Klotz, Jr.
  > Xerox Corporation
  > 
  > 
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  

FOLLOWUP 2:

  From: Mail Delivery Subsystem <MAILER-DAEMON@aptest.com>
  
  This is a MIME-encapsulated message
  
  --l5DKEErs006223.1181765654/htmlwg.mn.aptest.com
  
  The original message was received at Wed, 13 Jun 2007 15:14:07 -0500
  from htmlwg.mn.aptest.com [127.0.0.1]
  
     ----- The following addresses had permanent fatal errors -----
  <www-forms-editor@org>
      (reason: 550 Host unknown)
  
     ----- Transcript of session follows -----
  550 5.1.2 <www-forms-editor@org>... Host unknown (Name server: org: host not found)
  
  --l5DKEErs006223.1181765654/htmlwg.mn.aptest.com
  Content-Type: message/delivery-status
  
  Reporting-MTA: dns; htmlwg.mn.aptest.com
  Received-From-MTA: DNS; htmlwg.mn.aptest.com
  Arrival-Date: Wed, 13 Jun 2007 15:14:07 -0500
  
  Final-Recipient: RFC822; www-forms-editor@org
  Action: failed
  Status: 5.1.2
  Remote-MTA: DNS; org
  Diagnostic-Code: SMTP; 550 Host unknown
  Last-Attempt-Date: Wed, 13 Jun 2007 15:14:07 -0500
  
  --l5DKEErs006223.1181765654/htmlwg.mn.aptest.com
  Content-Type: message/rfc822
  Content-Transfer-Encoding: 8bit
  
  Return-Path: <xforms-issues@mn.aptest.com>
  Received: from htmlwg.mn.aptest.com (htmlwg.mn.aptest.com [127.0.0.1])
  	by htmlwg.mn.aptest.com (8.13.1/8.13.1) with ESMTP id l5DKE7rs006220;
  	Wed, 13 Jun 2007 15:14:07 -0500
  Date: Wed, 13 Jun 2007 15:14:07 -0500
  Message-Id: <200706132014.l5DKE7rs006220@htmlwg.mn.aptest.com>
  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  To: Leigh.Klotz@xerox.com
  Subject: Re: Last Call Comment: XForms 1.1 refers normatively to XForms 1.0 requirements but not XForms 1.1 requirements (PR#49)
  CC: w3c-forms@w3.org, www-forms-editor@org
  X-Loop: xforms-issues@mn.aptest.com
  
  > This may be a simple editing error, but the XForms 1.1 Working Draft [1]
  > in the Normative References section [2] refers via [3] to XForms 1.0
  > Requirements [4] but does not cite XForms 1.1 Requirements [5].
  > 
  > [1] http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req
  > [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm
  > [4] http://www.w3.org/TR/xhtml-forms-req
  > [5] http://www.w3.org/TR/xforms-11-req/
  > 
  > 
  > Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1
  > requirements?
  > 
  > 
  
  We removed the XForms 1.0 requirements and do not add XForms 1.1.
  
  > Leigh L. Klotz, Jr.
  > Xerox Corporation
  > 
  > 
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  
  --l5DKEErs006223.1181765654/htmlwg.mn.aptest.com--
  

FOLLOWUP 3:

  From: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
  
  Thank you. 
  
  -----Original Message-----
  From: Steven Pemberton [mailto:xforms-issues@mn.aptest.com] 
  Sent: Wednesday, June 13, 2007 1:25 PM
  To: Klotz, Leigh
  Cc: www-forms-editor@w3.org
  Subject: Re: Last Call Comment: XForms 1.1 refers normatively to XForms
  1.0 requirements but not XForms 1.1 requirements (PR#49)
  
  Leigh, thanks for your comment.
  
  > This may be a simple editing error, but the XForms 1.1 Working Draft
  [1]
  > in the Normative References section [2] refers via [3] to XForms 1.0
  > Requirements [4] but does not cite XForms 1.1 Requirements [5].
  >[1] http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req
  > [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm
  > [4] http://www.w3.org/TR/xhtml-forms-req
  > [5] http://www.w3.org/TR/xforms-11-req/
  >Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1
  > requirements?
  >
  
  We have resolved to remove the unreferenced XForms 1.0 requirements and
  therefore will not add XForms 1.1.
  
  Regards,
  Steven Pemberton
  For the Forms WG
  
  
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Leigh, thanks for your comment.
  
  > This may be a simple editing error, but the XForms 1.1 Working Draft [1]
  > in the Normative References section [2] refers via [3] to XForms 1.0
  > Requirements [4] but does not cite XForms 1.1 Requirements [5].
  >[1] http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req
  > [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm
  > [4] http://www.w3.org/TR/xhtml-forms-req
  > [5] http://www.w3.org/TR/xforms-11-req/
  >Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1
  > requirements?
  >
  
  We have resolved to remove the unreferenced XForms 1.0 requirements and
  therefore will not add XForms 1.1.
  
  Regards,
  Steven Pemberton
  For the Forms WG
  

REPLY 2:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  > This may be a simple editing error, but the XForms 1.1 Working Draft [1]
  > in the Normative References section [2] refers via [3] to XForms 1.0
  > Requirements [4] but does not cite XForms 1.1 Requirements [5].
  > 
  > [1] http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req
  > [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm
  > [4] http://www.w3.org/TR/xhtml-forms-req
  > [5] http://www.w3.org/TR/xforms-11-req/
  > 
  > 
  > Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1
  > requirements?
  > 
  > 
  
  We removed the XForms 1.0 requirements and do not add XForms 1.1.
  
  > Leigh L. Klotz, Jr.
  > Xerox Corporation
  > 
  > 
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG

4. Controls

4.1 xforms:select and blank value

PROBLEM ID: 90

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

NOTES:

  Erik agrees with the resolution and helped produce the spec-ready text.
  
  RESOLUTION: Select items with blanks or empty values do not affect the 
  storage value and these items should not be selectable by the user.
  
  ACTION: Erik Bruchez Erik to add text for select items with blanks or 
  empty values do not affect the storage value and these items should not 
  be selectable by the user (and have definition or better wording for blank).

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  What is supposed to happen with the following:
  
        <xforms:select ref="value">
            <xforms:label>Flavors</xforms:label>
            <xforms:item>
                <xforms:label>Empty</xforms:label>
                <xforms:value></xforms:value>
            </xforms:item>
            <xforms:item>
                <xforms:label>Chocolate</xforms:label>
                <xforms:value>chocolate</xforms:value>
            </xforms:item>
        </xforms:select>
  
  The key here is the first item value being empty.
  
  Now if I have the following in the instance:
  
        <value></value>
  
  Is the first item, "Empty". supposed to be visually selected?
  
  What if I have this:
  
        <value>chocolate</value>
  
  Clearly, "Chocolate" is selected. But then would "Empty" be selected?
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  
  
  

4.2 More on xforms:select storage

PROBLEM ID: 89

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

NOTES:

  Erik agrees with the resolution and helped produce the spec-ready text.
  
  RESOLUTION: issue 89 we propose that the behavior be non-destructive and 
  choose option 2a
  ACTION: Erik add text for issue 89 we propose that the behavior be 
  non-destructive and choose option 2a.

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  Assume again an instance containing the following:
  
      <value>vanilla strawberry elephant</value>
  
  and the following xforms:select control:
  
        <xforms:select ref="value">
            <xforms:label>Flavors</xforms:label>
            <xforms:item>
                <xforms:label>Chocolate</xforms:label>
                <xforms:value>chocolate</xforms:value>
            </xforms:item>
            <xforms:item>
                <xforms:label>Vanilla</xforms:label>
                <xforms:value>vanilla</xforms:value>
            </xforms:item>
            <xforms:item>
                <xforms:label>Strawberry</xforms:label>
                <xforms:value>strawberry</xforms:value>
            </xforms:item>
            <xforms:item>
                <xforms:label>Hazelnut</xforms:label>
                <xforms:value>hazelnut</xforms:value>
            </xforms:item>
        </xforms:select>
  
  Now it seems that the control will be out of range if I guess enough
   from the spec.
  
  Now what happens if I select "hazelnut" from the control?
  
  1. First, is the control functional at all if out of range? I don't
       read otherwise in the spec.
  
  2. If it is functional, then does it append the "halzenut" value to
       the sequence of values, or does it replace the current value
       entirely? I.e. which of the following does it produce:
  
       a. <value>vanilla strawberry elephant hazelnut</value>
       b. <value>vanilla strawberry hazelnut</value>
       c. (any other possibility?)
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  
  
  

4.3 Section 8

PROBLEM ID: 117

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  
  26) Section 8.1.1 - "If a form control violates its data binding
  restriction, an xforms-binding-exception must occur."  How can a form
  control violate its data binding restriction?  I would think that the bound
  data would violate the data binding restriction of the control.
  27) Section 8.1.1 - a bulleted list of "Form control must..." items, but no
  examples.  Any suggestions for  how I would "...render upon request an
  explanation of the current state of a form control..."?  And what is the
  request?
  28) Section 8.1.1 - the list of events that happen when a form control goes
   from being irrelevant to relevant -> xforms-value-changed only MIGHT be
  generated.  A control can become relevant without the value of the
  control's bound node changing at all.
  29) Section 8.1.5 - the description is duplicated.
  30) Section 8.3.3 - "This required element labels the containing form
  control with a descriptive label."  This isn't always required.  For
  example repeat, output, choices, group, and case.
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  Here are responses to a number of issues that you raised in a last call comment
  email on April 30.  Spec changes can be found in the editor's copy available
  from the Forms WG public site.  Please let us know if you have any further
  concerns about these issues.
  
  Thanks,
  John Boyer
  
  26) Section 8.1.1 - "If a form control violates its data binding
  restriction, an xforms-binding-exception must occur."  How can a form
  control violate its data binding restriction?  I would think that the bound
  data would violate the data binding restriction of the control.
  
  A form control can violate its data binding restriction by expressing
  a binding that resolves to a node of a forbidden datatype.  Each form
  control expresses its data binding restrictions.
  
  27) Section 8.1.1 - a bulleted list of "Form control must..." items, but no
  examples.  Any suggestions for  how I would "...render upon request an
  explanation of the current state of a form control..."?  And what is the
  request?
  
  That bullet point and the one following have been removed.  Diff-marked.
  
  28) Section 8.1.1 - the list of events that happen when a form control goes
  from being irrelevant to relevant -> xforms-value-changed only MIGHT be
  generated.  A control can become relevant without the value of the
  control's bound node changing at all.
  
  This was actually part of an erratum to XForms 1.0, not just new to 1.1.  The
  intent here was to issue xforms-value-changed to the control when it becomes
  relevant even if there was no change of value.  Implementations are not expected
  to store the state of UI controls when last they were relevant, nor are they
  required to store the changing states of controls based on their binding to a
  non-relevant node. And last, implementations need not then choose which state is
  the pertinent one for producing an xforms-value-changed.
  
  29) Section 8.1.5 - the description is duplicated.
  
  Done. Diff-marked.
  
  30) Section 8.3.3 - "This required element labels the containing form
  control with a descriptive label."  This isn't always required.  For
  example repeat, output, choices, group, and case.
  
  Fixed.  Diff-marked.  Improved wording of paragraph as well.
  

4.4 xforms:select storage

PROBLEM ID: 88

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

NOTES:

  Erik agrees with the resolution and helped produce the spec-ready text.
  
  Proposed resolution for issue 88: We agree that the control present an 
  out-of-range condition in this scenario, and to rewrite the paragraph to 
  clarify that behavior.
  ACTION: Erik Clarify pargraph about out ouf range state on select
  Nick Van den Bleeken: not sure i like append.  can't correct bad data 
  any more.

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  In section 8.1.10, I read:
  
      "For closed selections: If the initial instance value matches the
       storage value of one or more of the given items, those items are
       selected. If there is no match, no items are initially selected. If
       any selected values do not have a choice with a matching storage
       value, the form control must indicate an out-of-range condition."
  
  (Note that this dates back to XForms 1.0 first edition.)
  
  I have issues with this terminology.
  
  1. The term "storage value" for an item appears only in section 8.1.10
       and does not have a definition. It should have a clear definition,
       or another wording should be used.
  
  2. The term "matching" is quite informal. Do we mean that there is
       string equality? This should be clarified.
  
  3. "If any selected values [...]": selected where? I don't think we
       mean a selected item here. We probably mean that a value appears
       in the sequence of space-separated values?
  
  4. "[a value] does not have a choice with [...]": is this even
       English?
  
  I guess that #3 and #4 mean that if I have an instance like this:
  
      <value>vanilla strawberry elephant</value>
  
  and the following item values provided to the xforms:select control
  with a closed selection:
  
      chocolate
      vanilla
      strawberry
      hazelnut
  
  then the control indicates an out-of-range condition.
  
  Is my guess right?
  
  We should in my opinion:
  
  1. Clarify #3 and #4, that is the last sentence of the paragraph.
  
  2. Ideally, rewrite the whole thing to use a consistent terminology.
  
  This is another of these cases where I think what we are trying to
  specify is quite simple, but where the wording is imprecise and
  misleading.
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

4.5 [LC] 8.1.5 The output Element (+)

PROBLEM ID: 72

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  The group agrees: all controls should be default inline, and all MIP properties
  should be perceivable on attached controls without interaction
  
  This change is modestly substantive in that it does describe more behavior for
  the UI controls than was described before.  However, the risk of objection is
  quite low as it is describing agree upon styling defaults where previously form
  authors would have to always specify a value in order to achieve
  interoperability.  Hence, no functionality is lost if they maintain that
  specificity, and it is easy to implement the defaults across implementations.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#ui-output
  
  "It is used to display values from the instance, and is treated as
  display:inline for purposes of layout."
  
  This should say that its default styling is display:inline.
  
  Note that other controls do not have this information, which gets in
  the way of interoperability, since different implementations may have
  different defaults for controls.
  
  Similarly, the read-only, relevant, invalid, and required properties
  should be required to have some default value (I have used at least
  one implementation which required a style sheet before invalid values
  were visible.)
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Steven,
  
  We accepted your comments, and the spec will be updated accordingly.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > http://www.w3.org/TR/xforms11/#ui-output
  > 
  > "It is used to display values from the instance, and is treated as
  > display:inline for purposes of layout."
  > 
  > This should say that its default styling is display:inline.
  > 
  > Note that other controls do not have this information, which gets in
  > the way of interoperability, since different implementations may have
  > different defaults for controls.
  > 
  > Similarly, the read-only, relevant, invalid, and required properties
  > should be required to have some default value (I have used at least
  > one implementation which required a style sheet before invalid values
  > were visible.)
  > 
  > 

4.6 [LC] 8.3.2 The mediatype Element

PROBLEM ID: 73

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response

NOTES:

  Modified to just add value as an optional attribute to mediatype element in
  output.
  This is only modestly substantive in the sense that we added an attribute, but
  not substantive in the sense we do not expect any objections to the addition.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#ui-commonelems-mediatype
  
  We now have
  
      <output ref="piccy" mediatype="image/png">
  
  and
  
      <output ref="piccy"><mediatype ref="../type"/></output>
  
  It would be better if it used @value instead of @ref, since then you
  could write:
  
      <output ref="data"><mediatype value="concat('image/', type)"/></output>
  
  Even better, since the attribute is completely new, is to do away with
  the mediatype element altogether:
  
      <output ref="data" mediatype="../type"/>
  
  (which would require
      <output ref="data" mediatype="'image/png'">
  for the literal case.)
  
  The way that mediatype@ref has two different purposes depending on its
  parent element is nasty.
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  As you know from the face to face meeting, the working group accepted a modified
  form of this comment.
  
  To simplify authoring of the mediatype child of output, a value attribute has
  been added.  This helps address the mismatch you felt was problematic between
  using mediatype/@ref in upload vs. in output.
  
  However, the ref attribute was retained as an alternative because when upload
  and output are being used together, they both will have a mediatype element with
  a ref that indicates the same node.
  
  The results of the change are now available in the editor's draft available from
  the working group web site.
  
  Best regards,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#ui-commonelems-mediatype
  > 
  > We now have
  > 
  >     <output ref="piccy" mediatype="image/png">
  > 
  > and
  > 
  >     <output ref="piccy"><mediatype ref="../type"/></output>
  > 
  > It would be better if it used @value instead of @ref, since then you
  > could write:
  > 
  >     <output ref="data"><mediatype value="concat('image/', type)"/></output>
  > 
  > Even better, since the attribute is completely new, is to do away with
  > the mediatype element altogether:
  > 
  >     <output ref="data" mediatype="../type"/>
  > 
  > (which would require
  >     <output ref="data" mediatype="'image/png'">
  > for the literal case.)
  > 
  > The way that mediatype@ref has two different purposes depending on its
  > parent element is nasty.
  > 
  > 
  > 

4.7 Two descriptions of the output element

PROBLEM ID: 30

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Gary F Stevens" <gfsteven@us.ibm.com>
  
  
  
  
  
  In the XForms 1.1 Working Draft section 8.1.5 begins with two separate
  descriptions of the output element.  They are phrased slightly differently
   from each other, but only one of the two descriptions is needed.
  
  Gary F Stevens
  Software Group - Emerging Standards
  IBM/US/Raleigh-RTP
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  You are right. The first description is the original, and should just be
  deleted. Many thanks.
  
  Steven Pemberton
  For the Forms WG
  
  > In the XForms 1.1 Working Draft section 8.1.5 begins with two separate
  > descriptions of the output element.  They are phrased slightly differently
  >  from each other, but only one of the two descriptions is needed.
  > 
  > Gary F Stevens
  > Software Group - Emerging Standards
  > IBM/US/Raleigh-RTP
  > 
  > 

5. Events

5.1 LC: Clarify expectation of deleted-nodes property of xforms-delete

PROBLEM ID: 18

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree

NOTES:

  Need to remove notion of half-detached nodes.  Would like to determine the
  parents of deleted nodes, but there is no reasonable way to do this.
  This is only modestly substantive in that we removed a point feature that
  presented major anticipated implementation problems and that was not
  generalizable in the language anyway.  We do not expect objections to its
  removal.

ORIGINAL MESSAGE:

  From: "John Boyer" <boyerj@ca.ibm.com>
  
  In Section 4.4.6, the xforms-delete event is discussed.
  
  The deleted-nodes property states that the deleted "nodes are no longer
  referenced by their parents."  It is strongly implied but not stated that
  the detachment is only one way, i.e. that the nodes still reference their
  parents.
  
  It should be clarified that it is possible to traverse upward to the
  former ancestors of the deleted nodes.
  
  This should also be normatively stated in the section on the delete action
  (Section 9.3.6, bullet point 4).  Currently that text simply says the
  nodes are deleted but it leaves open to interpretation what deleted
  actually means.
  
  It should say that the nodes are detached from their parents and queued
  for destruction immediately before deferred update behavior.
  
  Finally, the behavior of properly destroying all 'deleted' nodes before
  deferred update behavior occurs should be mentioned at the beginning of
  Section 10 on XForms actions.
  
  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
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  It was necessary to remove this notion of half-detached nodes.  Although it
  would be nice to be able to determine the parents of deleted nodes so that
  behaviors can be taken based on the exact nodes deleted, but there is no
  reasonable way to do this that always works.  Moreover, for the cases that work
  via this method, the same cases already work with other event information.
  
  John Boyer
  
  > In Section 4.4.6, the xforms-delete event is discussed.
  > 
  > The deleted-nodes property states that the deleted "nodes are no longer
  > referenced by their parents."  It is strongly implied but not stated that
  > the detachment is only one way, i.e. that the nodes still reference their
  > parents.
  > 
  > It should be clarified that it is possible to traverse upward to the
  > former ancestors of the deleted nodes.
  > 
  > This should also be normatively stated in the section on the delete action
  > (Section 9.3.6, bullet point 4).  Currently that text simply says the
  > nodes are deleted but it leaves open to interpretation what deleted
  > actually means.
  > 
  > It should say that the nodes are detached from their parents and queued
  > for destruction immediately before deferred update behavior.
  > 
  > Finally, the behavior of properly destroying all 'deleted' nodes before
  > deferred update behavior occurs should be mentioned at the beginning of
  > Section 10 on XForms actions.
  > 
  > 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
  > 
  > 

5.2 LC: xforms-compute-exception and xforms-binding-exception

PROBLEM ID: 36

STATE: Suspended
EDIT: N/A
RESOLUTION: Accept
USER POSITION: Agree

NOTES:

  Accepted, but deferred

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  What this is about
  ------------------
  
  This comment is about xforms-compute-exception and
  xforms-binding-exception, in particular:
  
  * The clarity (or lack thereof) of the current wording.
  * The need for an xforms-compute-error event.
  
  The current text
  ----------------
  
  For reference:
  
  Section "4.5.4 The xforms-compute-exception Event" says:
  
      "Dispatched as an indication of: an error occurring during XPath
       evaluation for a model item property [...]"
  
  The introduction to section "7 XPath Expressions in XForms" says:
  
      "XPath expressions that are not syntactically valid, including
       attempted calls to undefined functions, result in an exception
       (4.5.4 The xforms-compute-exception Event), except for binding
       expressions, which produce a different exception (4.5.1 The
       xforms-binding-exception Event)."
  
  Section "7.6 The XForms Function Library" says:
  
      "If an error occurs in an XPath function, an
       xforms-compute-exception occurs if the function appears in the
       expression of a model item property. If the error occurs in a
       function that appears in any other XForms attribute that contains
       an XPath expression, such as nodeset, ref or at, then an
       xforms-binding exception occurs."
  
  Section "7.12 Extension Functions" says:
  
      "XForms Processors perform this check at the time the document is
      loaded, and stop processing by signaling an exception (4.5.4 The
      xforms-compute-exception Event) if the XForms document declares an
      extension function for which the processor does not have an
      implementation."
  
  One thing to keep in mind
  -------------------------
  
  As hinted by Mike Kay in his LC comments [1] from the XSL and XQuery
  WG, XPath 2.0 explicitly makes a distinction between two types of
  errors: static errors (which do not require evaluating expressions,
  i.e. typically syntactic errors) and dynamic errors (errors occurring
  while evaluating the XPath expression).
  
  I think that in XPath 1.0, the behavior of standard functions is
  designed so that you don't get dynamic errors. For example, converting
  a string to a number type will return NaN if the conversion fails,
  while with XPath 2.0 casting an xs:string that does not represent an
  integer to xs:integer will raise a runtime error.
  
  This said, while XPath 1.0 does not make this distinction explicitly,
  XForms does talk about a type of dynamic errors in the intro to
  section 7.6 under "if an error occurs in an XPath function", and also
  mentions errors occurring "during XPath evaluation" in section
  4.5.4. So we do have, in XForms 1.0, static AND dynamic XPath errors,
  whether these terms are used or not.
  
  The problems
  ------------
  
  I am confused by the current text, which in my eyes contradicts itself
  at times, and does not clearly lay out the intent of these events.
  
  1. Section 7 indicates with the words "binding expressions" that the
       intent of a "binding exception" is to signal there is an error with
       a binding, whether the syntax is incorrect or whether there is a
       runtime error. I understand this to regard any XPath expression not
       only in xforms:bind/@nodeset but also in @ref/@nodeset expressions
       that bind controls to instance data.
  
         Issue #1: Section 7.6 says that syntax errors in attribute @at
         dispatch xforms-binding-exception. I think that this is wrong, as
         @at does not define a binding at all.
  
       (Note that xforms-binding-exception can also be dispatched for
       mismatched ids, etc., but here I am only interested in XPath
       expressions).
  
  2. It seems that section 7.12 is the only place where the spec hints
       that the XForms engine must check the syntax of XPath expressions.
  
        Issue #2: It must be made 100% explicit that during XForms
        initialization (exact place TBD), every single XPath expression in
        the XForms document is checked for its syntax, and not only for
        undeclared extension functions. This includes XPath expressions on
        XForms actions, such as xforms:setvalue/@value, etc., XPath
        expressions in @if and @while attributes on actions as well, and
        also @context on actions. Such static XPath errors should dispatch
        xforms-binding-exception or xforms-compute-exception depending on
        whether the XPath expression is in a binding or not (see #4 below
        as well).
  
  3. xforms-binding-exception is not cancelable and halts XForms
       processing altogether. It seems reasonable to do this for MIP and
       control bindings, because there isn't much you can do with such an
       error in your XForms document. But what about other uses of @ref
       and @nodeset?
  
         Issue #3: Is it reasonable to dispatch xforms-binding-exception
         and fatally stop XForms processing for xforms:setvalue/@ref or
         xforms:insert/@nodeset?
  
       I think that the answer to this question is "yes" provided issue #2
       above is resolved to mandate that all expressions are checked for
       syntax during initialization.
  
  4. @ref and @nodeset on actions are single-node and node-set bindings
       respecively, but they don't act like MIP or control bindings.
  
         Issue #4: Should errors in XPath expressions on @ref and @nodeset
         on actions dispatch xforms-binding-exception or
         xforms-compute-exception?
  
       An action is not really "bound" to a node as a MIP or control
       is. So as a form author, I am not sure why xforms:setvalue/@ref
       would dispatch a different event from xforms:setvalue/@value.
  
  5. My understanding is that errors in other XPath expressions,
       including xforms:bind/@calculate, xforms:insert/@at,
       xforms:setvalue/@value, etc. should dispatch
       xforms-compute-exception.
  
       But the problem with this is that any error, whether static or
       dynamic, halts XForms engine processing altogether. This is not a
       huge problem with XPath 1.0, as mentioned above, since dynamic
       errors are fairly rare (if possible at all with the standard XPath
       1.0 function library) and most likely confined to extension
       functions.
  
       Still, it appears reasonable to think that you can recover from
       dynamic XPath errors, and this is certainly the case when such
       errors do not occur in bindings. This also prepares XForms for a
       future where XPath 2.0 is supported, as also suggested by Mike Kay
       in [1].
  
         Issue #5: Dynamic XPath errors should dispatch a new event:
         xforms-compute-error (and possibly xforms-binding-error), which
         do not halt XForms engine processing. Whether to support
         xforms-binding-error for MIP and control bindings can be
         discussed, but it would make sense for xforms:setvalue/@ref and
         the likes as those errors can often be recovered.
  
  A possible strategy
  -------------------
  
  Here is a tentative strategy based on the above:
  
  * Dispatch xforms-binding-exception for static XPath errors occurring
      in @ref and @nodeset expressions on xforms:bind and controls
      bindings. Static errors must be checked during XForms engine
      initialization.
  
  * Also dispatch xforms-binding-exception for dynamic XPath errors
      occurring in @ref and @nodeset expressions on xforms:bind and
      controls bindings.
  
  * Dispatch xforms-compute-exception for static XPath errors occurring
      anywhere else, including single-node or node-set bindings on
      actions. Static errors must be checked during XForms engine
      initialization.
  
  * Dispatch xforms-compute-error (a new event) for dynamic XPath errors
      occurring anywhere else.
  
  While this is done, the relevant text in the spec should be
  consolidated and clarified.
  
  -Erik
  
  [1] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0052.html
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Erik,
  
  The working group acknowledges that a richer array of exceptions, or possibly a
  more general exception with better context information, is needed to more
  accurately characterize the exceptions that occur when evaluating XPath
  expressions.  The bulk of the problem seems to be that binding exceptions are
  being issued for XPaths that are not strictly bindings. In one important case,
  we do already have a separate exception, compute exception, that is thrown
  instead of binding exception when a fatal error occurs in a MIP expression (i.e.
  any attribute of a bind element except for nodeset).  It would be fair to say
  though, that xforms-binding-exception is really being treated more like
  xforms-binding-or-xpath-exception at this time.
  
  The working group also acknowledges the utility of analyzing the cases currently
  associated with exceptions to find those that would be better to have as
  non-fatal errors.
  
  The working group resolved to accept these points and to defer the changes to a
  future version of XForms.
  
  Thank you,
  John Boyer
  
  > 
  > All,
  > 
  > What this is about
  > ------------------
  > 
  > This comment is about xforms-compute-exception and
  > xforms-binding-exception, in particular:
  > 
  > * The clarity (or lack thereof) of the current wording.
  > * The need for an xforms-compute-error event.
  > 
  > The current text
  > ----------------
  > 
  > For reference:
  > 
  > Section "4.5.4 The xforms-compute-exception Event" says:
  > 
  >     "Dispatched as an indication of: an error occurring during XPath
  >      evaluation for a model item property [...]"
  > 
  > The introduction to section "7 XPath Expressions in XForms" says:
  > 
  >     "XPath expressions that are not syntactically valid, including
  >      attempted calls to undefined functions, result in an exception
  >      (4.5.4 The xforms-compute-exception Event), except for binding
  >      expressions, which produce a different exception (4.5.1 The
  >      xforms-binding-exception Event)."
  > 
  > Section "7.6 The XForms Function Library" says:
  > 
  >     "If an error occurs in an XPath function, an
  >      xforms-compute-exception occurs if the function appears in the
  >      expression of a model item property. If the error occurs in a
  >      function that appears in any other XForms attribute that contains
  >      an XPath expression, such as nodeset, ref or at, then an
  >      xforms-binding exception occurs."
  > 
  > Section "7.12 Extension Functions" says:
  > 
  >     "XForms Processors perform this check at the time the document is
  >     loaded, and stop processing by signaling an exception (4.5.4 The
  >     xforms-compute-exception Event) if the XForms document declares an
  >     extension function for which the processor does not have an
  >     implementation."
  > 
  > One thing to keep in mind
  > -------------------------
  > 
  > As hinted by Mike Kay in his LC comments [1] from the XSL and XQuery
  > WG, XPath 2.0 explicitly makes a distinction between two types of
  > errors: static errors (which do not require evaluating expressions,
  > i.e. typically syntactic errors) and dynamic errors (errors occurring
  > while evaluating the XPath expression).
  > 
  > I think that in XPath 1.0, the behavior of standard functions is
  > designed so that you don't get dynamic errors. For example, converting
  > a string to a number type will return NaN if the conversion fails,
  > while with XPath 2.0 casting an xs:string that does not represent an
  > integer to xs:integer will raise a runtime error.
  > 
  > This said, while XPath 1.0 does not make this distinction explicitly,
  > XForms does talk about a type of dynamic errors in the intro to
  > section 7.6 under "if an error occurs in an XPath function", and also
  > mentions errors occurring "during XPath evaluation" in section
  > 4.5.4. So we do have, in XForms 1.0, static AND dynamic XPath errors,
  > whether these terms are used or not.
  > 
  > The problems
  > ------------
  > 
  > I am confused by the current text, which in my eyes contradicts itself
  > at times, and does not clearly lay out the intent of these events.
  > 
  > 1. Section 7 indicates with the words "binding expressions" that the
  >      intent of a "binding exception" is to signal there is an error with
  >      a binding, whether the syntax is incorrect or whether there is a
  >      runtime error. I understand this to regard any XPath expression not
  >      only in xforms:bind/@nodeset but also in @ref/@nodeset expressions
  >      that bind controls to instance data.
  > 
  >        Issue #1: Section 7.6 says that syntax errors in attribute @at
  >        dispatch xforms-binding-exception. I think that this is wrong, as
  >        @at does not define a binding at all.
  > 
  >      (Note that xforms-binding-exception can also be dispatched for
  >      mismatched ids, etc., but here I am only interested in XPath
  >      expressions).
  > 
  > 2. It seems that section 7.12 is the only place where the spec hints
  >      that the XForms engine must check the syntax of XPath expressions.
  > 
  >       Issue #2: It must be made 100% explicit that during XForms
  >       initialization (exact place TBD), every single XPath expression in
  >       the XForms document is checked for its syntax, and not only for
  >       undeclared extension functions. This includes XPath expressions on
  >       XForms actions, such as xforms:setvalue/@value, etc., XPath
  >       expressions in @if and @while attributes on actions as well, and
  >       also @context on actions. Such static XPath errors should dispatch
  >       xforms-binding-exception or xforms-compute-exception depending on
  >       whether the XPath expression is in a binding or not (see #4 below
  >       as well).
  > 
  > 3. xforms-binding-exception is not cancelable and halts XForms
  >      processing altogether. It seems reasonable to do this for MIP and
  >      control bindings, because there isn't much you can do with such an
  >      error in your XForms document. But what about other uses of @ref
  >      and @nodeset?
  > 
  >        Issue #3: Is it reasonable to dispatch xforms-binding-exception
  >        and fatally stop XForms processing for xforms:setvalue/@ref or
  >        xforms:insert/@nodeset?
  > 
  >      I think that the answer to this question is "yes" provided issue #2
  >      above is resolved to mandate that all expressions are checked for
  >      syntax during initialization.
  > 
  > 4. @ref and @nodeset on actions are single-node and node-set bindings
  >      respecively, but they don't act like MIP or control bindings.
  > 
  >        Issue #4: Should errors in XPath expressions on @ref and @nodeset
  >        on actions dispatch xforms-binding-exception or
  >        xforms-compute-exception?
  > 
  >      An action is not really "bound" to a node as a MIP or control
  >      is. So as a form author, I am not sure why xforms:setvalue/@ref
  >      would dispatch a different event from xforms:setvalue/@value.
  > 
  > 5. My understanding is that errors in other XPath expressions,
  >      including xforms:bind/@calculate, xforms:insert/@at,
  >      xforms:setvalue/@value, etc. should dispatch
  >      xforms-compute-exception.
  > 
  >      But the problem with this is that any error, whether static or
  >      dynamic, halts XForms engine processing altogether. This is not a
  >      huge problem with XPath 1.0, as mentioned above, since dynamic
  >      errors are fairly rare (if possible at all with the standard XPath
  >      1.0 function library) and most likely confined to extension
  >      functions.
  > 
  >      Still, it appears reasonable to think that you can recover from
  >      dynamic XPath errors, and this is certainly the case when such
  >      errors do not occur in bindings. This also prepares XForms for a
  >      future where XPath 2.0 is supported, as also suggested by Mike Kay
  >      in [1].
  > 
  >        Issue #5: Dynamic XPath errors should dispatch a new event:
  >        xforms-compute-error (and possibly xforms-binding-error), which
  >        do not halt XForms engine processing. Whether to support
  >        xforms-binding-error for MIP and control bindings can be
  >        discussed, but it would make sense for xforms:setvalue/@ref and
  >        the likes as those errors can often be recovered.
  > 
  > A possible strategy
  > -------------------
  > 
  > Here is a tentative strategy based on the above:
  > 
  > * Dispatch xforms-binding-exception for static XPath errors occurring
  >     in @ref and @nodeset expressions on xforms:bind and controls
  >     bindings. Static errors must be checked during XForms engine
  >     initialization.
  > 
  > * Also dispatch xforms-binding-exception for dynamic XPath errors
  >     occurring in @ref and @nodeset expressions on xforms:bind and
  >     controls bindings.
  > 
  > * Dispatch xforms-compute-exception for static XPath errors occurring
  >     anywhere else, including single-node or node-set bindings on
  >     actions. Static errors must be checked during XForms engine
  >     initialization.
  > 
  > * Dispatch xforms-compute-error (a new event) for dynamic XPath errors
  >     occurring anywhere else.
  > 
  > While this is done, the relevant text in the spec should be
  > consolidated and clarified.
  > 
  > -Erik
  > 
  > [1] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0052.html
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

5.3 Value changes upon instance replacement

PROBLEM ID: 50

STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree

NOTES:

  JB: Initiallly I agreed, but now that I attempt to make some spec-ready text,
  it
  is not so clear.  For better or worse, xforms-value-changed indicates that *the
  value of* the bound node has changed, not that the bound node itself has
  changed.
  
  I tried to modify Bullet point 2 so that it could include instance replacement
  as another means for changing a UI control's value.  But unfortunately,
  xforms-value-changed does not track UI control value changes; it tracks data
  value changes.  So, the problem resulted that my spec change caused it to be
  the
  case that if one form control changed its node binding to point to a new node,
  then other controls which were not changed at all would also receive
  xforms-value-changed.
  
  This is starting to feel more like a feature request for XForms 1.2.  It might
  be possible to put in enough band-aid hacks to make XForms 1.1 do what is
  desired here, but we seem to need a different feature here because
  value-changed, like all the other events, is associated with a model item
  property (the value), and not with specific controls.  It seems like we need
  something like an xforms-control-state event with context info that provides
  the
  value and state of all MIPs for the bound node.  This could be dispatched on
  startup as well as any time something changes (the node binding, the value of
  the node binding, or a MIP).
  
  Maybe a completely different design is needed, but trying to bend
  xforms-value-changed to suit this use case looks problematic because, for
  better
  or worse, it doesn't appear to have been designed to accommodate it.

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  At the moment, I don't think this is clearly specified to happen.
  
  Use case:
  
  1. <xforms:input ref="name">
  
  2. The instance containing "name" is replaced.
  
  3. Section 11.2 specifies that a refresh must take place. However, no
       node of the new instance is marked as having changed as I
       understand it. 4.3.4 says "If the value of an instance data node
       was changed, then the node must be marked for dispatching the
       xforms-value-changed event.". But in this case, the value of the
       node hasn't changed because the node is just freshly created from
       the instance replacement.
  
  4. Consequence: no xforms-value-changed is fired.
  
  This behavior is very non-intuitive because you can replace an
  instance under controls' feet and while the control may update their
  values in the UI, no xforms-value-changed is fired.
  
  This means that you cannot reliably use events to determine if the
  value of a control has changed or not. I think that this should be
  possible, or the usefulness of value-changed-events is greatly
  reduced.
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Erik,
  
  we recognize the problem, but defer changes to MIP events for now because we
  need a broader based redesign of events for controls and possibly also for
  model.
  
  Regards,
  Ulrich Nicolas Lissé
  
  For the Forms WG> All,
  > 
  > At the moment, I don't think this is clearly specified to happen.
  > 
  > Use case:
  > 
  > 1. <xforms:input ref="name">
  > 
  > 2. The instance containing "name" is replaced.
  > 
  > 3. Section 11.2 specifies that a refresh must take place. However, no
  >      node of the new instance is marked as having changed as I
  >      understand it. 4.3.4 says "If the value of an instance data node
  >      was changed, then the node must be marked for dispatching the
  >      xforms-value-changed event.". But in this case, the value of the
  >      node hasn't changed because the node is just freshly created from
  >      the instance replacement.
  > 
  > 4. Consequence: no xforms-value-changed is fired.
  > 
  > This behavior is very non-intuitive because you can replace an
  > instance under controls' feet and while the control may update their
  > values in the UI, no xforms-value-changed is fired.
  > 
  > This means that you cannot reliably use events to determine if the
  > value of a control has changed or not. I think that this should be
  > possible, or the usefulness of value-changed-events is greatly
  > reduced.
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 
  > 

5.4 Section 4

PROBLEM ID: 115

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response

NOTES:

  WG decided that all are editorial except 15 and 16, which I will move to
  separate issues.
  Modify and accept because responses to 20 and 21 do not make changes as this
  material in 4.7.1 and 4.7.2 is not intended to be read without also reading the
  preamble in 4.7.  Adding text to 4.7.1 to clarify amounted to repeating the
  preamble.

ORIGINAL MESSAGE:

  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  
  15) Section 4.2.1 - item #2 - it mentions @resource but not what happens if
  there is a host-language defined linking attribute.
  16) Section 4.3.2 - mentions the special case of focusing a repeat, but not
  the special cases of group and switch.  Why not?
  17) Section 4.3.5 - "...then either the xforms-valid event must be marked
  for dispatch if the node changes from valid to invalid..." I assume that is
  a typo?  Other way around, I'd think.
  18) Section 4.3.6 - the paragraph that mentions 'circular dependency' is
  pretty confusing on the whole.  Could really use an example or two,
  especially the circular dependency part.
  19) Section 4.6.9 - doesn't mention the xforms-submit-serialize event.
  20) Section 4.7.1 - I found the second paragraph very confusing.
  21) Section 4.7.2 - "However, if the target bind element has one or more
  bind element ancestors, then the identified bind may be a target element
  that is associated with more than one target bind object."  Huh?
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  The following are responses to a number of issues you raised in an Email dated
  April 30th.  Please let us know if you have any further concerns about these
  issues.  The changes can be viewed in the editor's draft of the spec appearing
  on the working group website.
  
  Thanks,
  John Boyer
  
  17) Section 4.3.5 - "...then either the xforms-valid event must be marked
  for dispatch if the node changes from valid to invalid..." I assume that is
  a typo?  Other way around, I'd think.
  
  Fixed. Not diff-marked.
  
  18) Section 4.3.6 - the paragraph that mentions 'circular dependency' is
  pretty confusing on the whole.  Could really use an example or two,
  especially the circular dependency part.
  
  Examples were added.  Diff marked.
  
  19) Section 4.6.9 - doesn't mention the xforms-submit-serialize event.
  
  Done. Diff-marked.
  
  20) Section 4.7.1 - I found the second paragraph very confusing.
  
  It is necessary to consider the parse tree of the document, annotated 
  by run-time objects generated for and associated with the document markup.
  The referring object that contains an IDREF appears at location X
  in the parse tree, and the element bearing the matching ID is at
  location Y in the parse tree.  Take the paths of ancestors from
  X to root element and from Y to root.  X and Y will have some
  ancestors in common and some that are not.
  This subsection is not intended to be read separately from its 
  immediately containing section (4.7).
  
  
  21) Section 4.7.2 - "However, if the target bind element has one or more
  bind element ancestors, then the identified bind may be a target element
  that is associated with more than one target bind object."  Huh?
  
  This section is talking about the difference between declared bind
  elements and run-time bind objects.  Suppose the inner bind is the 
  target element of an IDREF.  The inner bind is associated with one 
  bind object for each node of the nodeset of an outer bind.
  This subsection is not intended to be read separately from its 
  immediately containing section (4.7).
  

5.5 [LC: editorial] 4.1 Events Overview

PROBLEM ID: 57

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#rpm-events
  
  In the overview table, xforms-rebuild should be moved to after
  xforms-recalculate (to match the order that they are described).
  xforms-submit-error should be moved to the Error indications section.
  xforms-output-error is missing from the overview.
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Steven,
  
  You are right. We will update the spec accordingly. 
  
  Many thanks.
  
  Nick Van den Bleeken
  For the Forms WG
  > 
  > http://www.w3.org/TR/xforms11/#rpm-events
  > 
  > In the overview table, xforms-rebuild should be moved to after
  > xforms-recalculate (to match the order that they are described).
  > xforms-submit-error should be moved to the Error indications section.
  > xforms-output-error is missing from the overview.
  > 
  > 

5.6 Section 9

PROBLEM ID: 155

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  The editor's draft contains spec-ready text for this in 4.3.2.

ORIGINAL MESSAGE:

  From: aaronr@us.ibm.com
  
  Full_Name: Aaron Reed
  Submission from: (NULL) (32.97.110.142)
  Submitted by: boyerj
  
  
  Date: Mon, 30 Apr 2007 23:56:50 +0200
  To: www-forms-editor@w3.org
  Subject: Section 9
  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  16) Section 4.3.2 - mentions the special case of focusing a repeat, but not
  the special cases of group and switch.  Why not?
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  We updated the spec accordingly[1]. 
  
  The latest editor's draft available from the Forms WG home page contains a
  correction.  Please see the diff-marked version.
  
  [1] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-focus
  
  > Full_Name: Aaron Reed
  > Submission from: (NULL) (32.97.110.142)
  > Submitted by: boyerj
  > 
  > 
  > Date: Mon, 30 Apr 2007 23:56:50 +0200
  > To: www-forms-editor@w3.org
  > Subject: Section 9
  > From: "Aaron Reed" <aaronr@us.ibm.com>
  > 
  > 16) Section 4.3.2 - mentions the special case of focusing a repeat, but not
  > the special cases of group and switch.  Why not?
  > 
  > 

5.7 [LC] 4.3.6 The xforms-recalculate Event

PROBLEM ID: 95

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  
  http://www.w3.org/TR/xforms11/#evt-recalculate
  
  Says: "Note:
  
  Authors should not refer to the current node's value in calculate
  expressions because the effect is not well-defined. Other model item
  properties, such as required or readonly, however, are well-defined in the
  presence of self-references."
  
  Are we sure we agree? I believe I have seen XForms that have ".+1".
  
  Steven
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Steven
  
  Many thanks for this comment. We have changed the spec accordingly.
  
  Best wishes,
  
  Nick Van den Bleeken
  For the Forms WG
  > 
  > 
  > http://www.w3.org/TR/xforms11/#evt-recalculate
  > 
  > Says: "Note:
  > 
  > Authors should not refer to the current node's value in calculate
  > expressions because the effect is not well-defined. Other model item
  > properties, such as required or readonly, however, are well-defined in the
  > presence of self-references."
  > 
  > Are we sure we agree? I believe I have seen XForms that have ".+1".
  > 
  > Steven
  > 
  > 

5.8 XForms 1.1 Last Call: comment about 4.4.5 The xforms-insert Event

PROBLEM ID: 108

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree

NOTES:

  Final resolution was actually to remove the binding property altogether since it
  can only be used as a hack.  Erik participated in the final discussion, which is
  whya second reply was not sent.

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  This is a comment about the "binding" property or these sections.
  Section 4.4.5 says:
  
  "The attribute value of the insert action's nodeset or bind attribute."
  
  However, both @bind and @nodeset are optional with xforms:insert. We
  should say what the "binding" property returns when this occurs.
  
  By the way, I believe I raised this in the past already, but I am not
  sure why this property is useful anyway. I would suggest simply getting
  rid of it unless a compelling use case for it is proposed.
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Erik,
  
  we accept your request to clarify that the empty is string is returned by insert
  event binding if none is specified.  We also ask for clarification on the
  feature and its use case, because in general, it is not possible for the form
  author to resolve the value without knowing the context and without knowing
  whether the binding is a bind IDREF or an XPath expression.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  > All,
  > 
  > This is a comment about the "binding" property or these sections.
  > Section 4.4.5 says:
  > 
  > "The attribute value of the insert action's nodeset or bind attribute."
  > 
  > However, both @bind and @nodeset are optional with xforms:insert. We
  > should say what the "binding" property returns when this occurs.
  > 
  > By the way, I believe I raised this in the past already, but I am not
  > sure why this property is useful anyway. I would suggest simply getting
  > rid of it unless a compelling use case for it is proposed.
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

5.9 LC: Initial sending of MIP events

PROBLEM ID: 29

STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree

NOTES:

  JB: This should be deferred for consideration as a future feature because the
  working group had valid reasons for not dispatching these events on
  initialization (and also not on instance replacement, if memory serves).
  
  The WG did not want xforms-invalid being dispatched on startup because it
  anticipated form authors wanting to hook xforms-invalid and present a message
  action (or ephemeral message).
  
  The solution to the problem might involve eventually deprecating message as an
  action, but it is too soon to tell.  However, it is agreed that there are other
  use cases where even having xforms-invalid fire on startup can be useful, such
  as creating a list of all incorrect things on a form when it starts up.  But
  this is a more sophisticated use case than a simple message, so it appears to
  be
  a feature request.

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  XForms 1.1 is much more specific than XForms 1.0 about sending MIP
  events, in particular what events to send when controls become
  relevant and non-relevant. This is good. The motivation for this was,
  in my opinion, to make the MIP events actually useful, because they
  now can be used to reliably track the status of controls.
  
  However, there is one hole: the spec does not mention that any MIP
  events should be sent during XForms engine initialization. In
  particular, there is no initial xforms-refresh, or otherwise
  requirement that MIP events should be dispatched upon initialization.
  
  This means that it is currently not possible to determine the initial
  status (in particular, validity) of the controls.
  
  This affects for example the use case of creating an error summary
  that tracks the validity of controls in your page.
  
  I think that controls should initially dispatch MIP events so as to
  make this use case possible.
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Erik,
  
  we recognize the problem, but defer changes to MIP events for now because we
  need a broader based redesign of events for controls and possibly also for
  model.
  
  Regards,
  Ulrich Nicolas Lissé
  
  For the Forms WG
  
  > All,
  > 
  > XForms 1.1 is much more specific than XForms 1.0 about sending MIP
  > events, in particular what events to send when controls become
  > relevant and non-relevant. This is good. The motivation for this was,
  > in my opinion, to make the MIP events actually useful, because they
  > now can be used to reliably track the status of controls.
  > 
  > However, there is one hole: the spec does not mention that any MIP
  > events should be sent during XForms engine initialization. In
  > particular, there is no initial xforms-refresh, or otherwise
  > requirement that MIP events should be dispatched upon initialization.
  > 
  > This means that it is currently not possible to determine the initial
  > status (in particular, validity) of the controls.
  > 
  > This affects for example the use case of creating an error summary
  > that tracks the validity of controls in your page.
  > 
  > I think that controls should initially dispatch MIP events so as to
  > make this use case possible.
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

5.10 [LC] 4.5.5 The xforms-version-exception Event

PROBLEM ID: 96

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#evt-versionException
  
  The property here is called "errorinformation", but the equivalent
  property in the previous section is called "error-message" (and all other
  sections seem to use a hyphen too).
  
  I propose it should be called "error-information"
  
  Steven
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The working group agrees, and the change is available in the editor's draft.
  
  Thank you,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#evt-versionException
  > 
  > The property here is called "errorinformation", but the equivalent
  > property in the previous section is called "error-message" (and all other
  > sections seem to use a hyphen too).
  > 
  > I propose it should be called "error-information"
  > 
  > Steven
  > 
  > 

5.11 [LC] 4.4.21 The xforms-output-error Event

PROBLEM ID: 60

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  Need better words to say that error happens on first attempt to render given
  data and another error happens if data changes or bound node changes.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#evt-output-error
  
  Should be moved to section 4.5 Error Indications
  
  In the sentence: "Dispatched by the processor immediately after the
  first failure of an output to render or update the rendition of
  content."
  
  What does "first" mean here? The first failure of any output? The
  first failure of each output? The first failure of each invocation of
  an output?
  
  It is not clear here what causes such a failure. Please link to 8.1.5
  The output Element http://www.w3.org/TR/xforms11/#ui-output
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The working group accepted your last call comment, and the changes you requested
  are now available in the editor's draft available from the working group home
  page.
  
  It was necessary to tighten up some language in xforms-refresh so that it could
  be made clear that the occurrence of the event corresponded to failures that
  occur either on control creation or during refresh.
  
  Thank you,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#evt-output-error
  > 
  > Should be moved to section 4.5 Error Indications
  > 
  > In the sentence: "Dispatched by the processor immediately after the
  > first failure of an output to render or update the rendition of
  > content."
  > 
  > What does "first" mean here? The first failure of any output? The
  > first failure of each output? The first failure of each invocation of
  > an output?
  > 
  > It is not clear here what causes such a failure. Please link to 8.1.5
  > The output Element http://www.w3.org/TR/xforms11/#ui-output
  > 
  > 

5.12 [LC: Editorial] 4.5.5 The xforms-version-exception Event

PROBLEM ID: 61

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

NOTES:

  Steven was present for WG discussion where this was accepted, so no reply was
  sent.
  
  Use wording from description in the model element of @version

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#evt-versionException
  
  Lacks a description
  

5.13 [LC: editorial] 4.4.20 The xforms-submit-error Event

PROBLEM ID: 59

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

NOTES:

  Steven was present for WG discussion where this was accepted, so no reply was
  sent.
  
  Move 4.4.20 (and 4.4.21) to Section 4.5

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#evt-submit-error
  
  Should be moved to section 4.5 Error Indications
  

6. Incoming

Messages in this directory have been submitted to the system, but have not yet been evaluated.

7. MIPs

7.1 [LC] 6.1.3 The required Property

PROBLEM ID: 102

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#model-prop-required
  
  "An XForms Processor may provide an indication that a form control is
  required, and may provide immediate feedback, including limiting
  navigation."
  
  While the readonly property says:
  "Form controls bound to instance data with the readonly model item
  property should indicate that entering or changing the value is not
  allowed."
  
  Relevant says:
  "In general, when true, associated form controls should be made visible.
  When false, associated form controls (and any children) and group and
  switch elements (including content) must be made unavailable, removed from
  the navigation order, and not allowed focus."
  
  The type and constraint MIPs say nothing about display (though there is
  probably something somewhere).
  
  1. I think that the processor SHOULD provide information that a value is
  required in bound controls, in the same way as readonly says.
  
  2. I think we should say something in the type and constraint MIPs, even
  if it's only a cross-reference.
  
  Steven
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Steven,
  
  We accepted your comments, and the spec will be updated accordingly.
  
  Regards,
  
  Nick Van den Bleeken
  > 
  > http://www.w3.org/TR/xforms11/#model-prop-required
  > 
  > "An XForms Processor may provide an indication that a form control is
  > required, and may provide immediate feedback, including limiting
  > navigation."
  > 
  > While the readonly property says:
  > "Form controls bound to instance data with the readonly model item
  > property should indicate that entering or changing the value is not
  > allowed."
  > 
  > Relevant says:
  > "In general, when true, associated form controls should be made visible.
  > When false, associated form controls (and any children) and group and
  > switch elements (including content) must be made unavailable, removed from
  > the navigation order, and not allowed focus."
  > 
  > The type and constraint MIPs say nothing about display (though there is
  > probably something somewhere).
  > 
  > 1. I think that the processor SHOULD provide information that a value is
  > required in bound controls, in the same way as readonly says.
  > 
  > 2. I think we should say something in the type and constraint MIPs, even
  > if it's only a cross-reference.
  > 
  > Steven
  > 
  > 

7.2 Fw: when and how readonly MIP prevents data mutations

PROBLEM ID: 176

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree

NOTES:

  With difficulty, the working group decided that readonly is an inviolate
  property of the model indicating that nothing is allowed to change the content
  nor attribute axis of a node whose readonly MIP is true.

ORIGINAL MESSAGE:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 001AF15688257331_=
  Content-Type: text/plain; charset="US-ASCII"
  
  ----- Forwarded by John Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----
  
  Vlad Trakhtenberg/CanWest/IBM@IBMCA 
  Sent by: www-forms-request@w3.org
  08/04/2007 12:00 PM
  
  To
  www-forms-editor@w3.org
  cc
  www-forms@w3.org
  Subject
  when and how readonly MIP prevents data mutations
  
  
  
  
  
  
  
  Dear WG & Editor, 
  
  I think the XForms readonly model item property is not defined in clear 
  enough terms, esp. from the implementer's perspective. This lack of 
  clarity persists in the current XForms 1.1 draft. The section 6.1.2 says: 
  Description: describes whether the value (!) is restricted from changing. 
  (*)
           ...
  Then it follows: 
  When evaluating to true, this model item property indicates that the 
  XForms Processor should not allow any (!) changes to the bound instance 
  data node. (**) 
  In addition to restricting value changes, the readonly model item property 
  provides a hint to the XForms user interface. Form controls bound to 
  instance data with the readonly model item property should indicate that 
  entering or changing the value is not allowed.(***) 
  
  
  1. Let's assume for a moment that an implementer should interpret (**) 
  literally, this would mean that all calculate properties shall by default 
  fail to change their respective instance nodes since for all the said 
  nodes the readonly property will evaluate to true() by default. 
  2.  Again assuming that the readonly node is totally immutable suggests 
  that there are omissions or in the sections of the draft describing 
  processing of the insert, delete, setvalue, and reset actions as well as 
  submissions with replace="instance" or "text". Notably, there is no 
  defined response if an attempt is made to change 'readonly' node by these 
  means. 
  3. A side issue with (**) is that if an application is to use instance 
  document  via exposed DOM interfaces [getInstanceDocument()] it is 
  expected to use DOM methods to possibly mutate it (that's why the 
  rebuild(), etc are for) and since there is no DOM access to MIPs there is 
  no way the application can honour the 'no-changes-to-readonly-nodes' rule. 
  
  
  To sum it up, I can clearly see how useful and mostly straight forward 
  (with the possible exception of 'readonly' trigger & submit.) is the 
  application of the readonly property by Form controls (as in ***) However, 
  in my opinion, the use of this property to restrict data mutations by 
  other means is either misplaced or underspec'd. 
  
  Best regards, 
  Vlad Trakhtenberg 
    
  --=_alternative 001AF15688257331_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <br><font size=2 face="sans-serif"><br>
  </font>
  <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John
  Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----</font>
  <br>
  <table width=100%>
  <tr valign=top>
  <td width=40%><font size=1 face="sans-serif"><b>Vlad Trakhtenberg/CanWest/IBM@IBMCA</b>
  </font>
  <br><font size=1 face="sans-serif">Sent by: www-forms-request@w3.org</font>
  <p><font size=1 face="sans-serif">08/04/2007 12:00 PM</font>
  <td width=59%>
  <table width=100%>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">To</font></div>
  <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">cc</font></div>
  <td><font size=1 face="sans-serif">www-forms@w3.org</font>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">Subject</font></div>
  <td><font size=1 face="sans-serif">when and how readonly MIP prevents data
  mutations</font></table>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br>
  <br>
  <br><font size=2 face="sans-serif"><br>
  Dear WG &amp; Editor,</font><font size=3> <br>
  </font><font size=2 face="sans-serif"><br>
  I think the XForms <b>readonly</b> model item property is not defined in
  clear enough terms, esp. from the implementer's perspective. This lack
  of clarity persists in the current XForms 1.1 draft. The section <b>6.1.2</b>
  says: </font>
  <p><font size=3 face="sans-serif">Description: describes whether the <i>value</i>
  (!) is restricted from changing. (*)</font><font size=2 face="sans-serif"><br>
   &nbsp; &nbsp; &nbsp; &nbsp; ...<br>
  Then it follows:</font><font size=3> </font>
  <p><font size=3 face="sans-serif">When evaluating to true, this model item
  property indicates that the XForms Processor should not allow <i>any</i>
  (!) changes to the bound instance data node. (**)</font><font size=3> </font>
  <p><font size=3 face="sans-serif"><i>In addition</i> to restricting <i>value</i>
  changes, the readonly model item property provides a hint to the XForms
  user interface. Form controls bound to instance data with the readonly
  model item property should indicate that entering or changing the value
  is not allowed.(***)</font><font size=3> <br>
  <br>
  </font><font size=2 face="sans-serif"><br>
  1. Let's assume for a moment that an implementer should interpret (**)
  literally, this would mean that all <b>calculate</b> properties shall by
  default fail to change their respective instance nodes since for all the
  said nodes the <b>readonly</b> property will evaluate to true() by default.</font><font size=3>
  </font><font size=2 face="sans-serif"><br>
  2. &nbsp;Again assuming that the readonly node is totally immutable suggests
  that there are omissions or in the sections of the draft describing processing
  of the <b>insert</b>, <b>delete</b>, <b>setvalue</b>, and <b>reset </b>actions
  as well as submissions with <b>replace</b>=&quot;instance&quot; or &quot;text&quot;.
  Notably, there is no defined response if an attempt is made to change 'readonly'
  node by these means. <br>
  3. A side issue with </font><font size=3 face="sans-serif">(**)</font><font size=2 face="sans-serif">
  is that if an application is to use instance document &nbsp;via exposed
  DOM interfaces </font><font size=3>[getInstanceDocument()] </font><font size=2 face="sans-serif">it
  is expected to use DOM methods to possibly mutate it (that's why the rebuild(),
  etc are for) and since there is no DOM access to MIPs there is no way the
  application can honour the 'no-changes-to-readonly-nodes' rule.</font><font size=3>
  <br>
  </font><font size=2 face="sans-serif"><br>
  To sum it up, I can clearly see how useful and mostly straight forward
  (with the possible exception of 'readonly' trigger &amp; submit.) is the
  application of the <b>readonly</b> property by Form controls (as in ***)
  However, in my opinion, the use of this property to restrict data mutations
  by other means is either misplaced or underspec'd.</font><font size=3>
  <br>
  </font><font size=2 face="sans-serif"><br>
  Best regards,</font><font size=3> </font><font size=2 face="sans-serif"><br>
  Vlad Trakhtenberg</font><font size=3> </font><font size=2 face="sans-serif"><br>
   </font><font size=3>&nbsp;</font>
  --=_alternative 001AF15688257331_=--
  

FOLLOWUP 1:

  From: John Boyer <xforms-issues@aptest.com>
  
  Hi Vlad,
  
  The working group agrees that the applicability of readonly is underspecified.
  The working group decided that readonly is an inviolate property of the model. 
  This means that form controls cannot modify readonly nodes to which they are
  bound, of course, but it also means that XForms actions and submissions have
  restrictions as well.  Specifically, neither setvalue nor text replacement
  submission can modify a readonly node and neither insert, delete nor instance
  replacement submission can modify a node whose parent is readonly.
  
  The reason for checking the parent node in the case of insert is clear: the node
  could not be readonly until after it is inserted.  In the case of delete and
  instance replacement, the view is that node deletion does not change the node. 
  However, node insertion or deletion (and hence replacement) does change the
  *conten* or attribute axis of the parent, which is what readonly is intended to
  protect.
  
  The editor's draft available from the working group page has been updated to
  reflect these substantive changes to XForms 1.1.  Please let us know if you have
  any further concerns regarding the changes made.
  
  Thanks,
  John Boyer
  
  > This is a multipart message in MIME format.
  > --=_alternative 001AF15688257331_=
  > Content-Type: text/plain; charset="US-ASCII"
  > 
  > ----- Forwarded by John Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----
  > 
  > Vlad Trakhtenberg/CanWest/IBM@IBMCA 
  > Sent by: www-forms-request@w3.org
  > 08/04/2007 12:00 PM
  > 
  > To
  > www-forms-editor@w3.org
  > cc
  > www-forms@w3.org
  > Subject
  > when and how readonly MIP prevents data mutations
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > Dear WG & Editor, 
  > 
  > I think the XForms readonly model item property is not defined in clear 
  > enough terms, esp. from the implementer's perspective. This lack of 
  > clarity persists in the current XForms 1.1 draft. The section 6.1.2 says: 
  > Description: describes whether the value (!) is restricted from changing. 
  > (*)
  >          ...
  > Then it follows: 
  > When evaluating to true, this model item property indicates that the 
  > XForms Processor should not allow any (!) changes to the bound instance 
  > data node. (**) 
  > In addition to restricting value changes, the readonly model item property 
  > provides a hint to the XForms user interface. Form controls bound to 
  > instance data with the readonly model item property should indicate that 
  > entering or changing the value is not allowed.(***) 
  > 
  > 
  > 1. Let's assume for a moment that an implementer should interpret (**) 
  > literally, this would mean that all calculate properties shall by default 
  > fail to change their respective instance nodes since for all the said 
  > nodes the readonly property will evaluate to true() by default. 
  > 2.  Again assuming that the readonly node is totally immutable suggests 
  > that there are omissions or in the sections of the draft describing 
  > processing of the insert, delete, setvalue, and reset actions as well as 
  > submissions with replace="instance" or "text". Notably, there is no 
  > defined response if an attempt is made to change 'readonly' node by these 
  > means. 
  > 3. A side issue with (**) is that if an application is to use instance 
  > document  via exposed DOM interfaces [getInstanceDocument()] it is 
  > expected to use DOM methods to possibly mutate it (that's why the 
  > rebuild(), etc are for) and since there is no DOM access to MIPs there is 
  > no way the application can honour the 'no-changes-to-readonly-nodes' rule. 
  > 
  > 
  > To sum it up, I can clearly see how useful and mostly straight forward 
  > (with the possible exception of 'readonly' trigger & submit.) is the 
  > application of the readonly property by Form controls (as in ***) However, 
  > in my opinion, the use of this property to restrict data mutations by 
  > other means is either misplaced or underspec'd. 
  > 
  > Best regards, 
  > Vlad Trakhtenberg 
  >   
  > --=_alternative 001AF15688257331_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <br><font size=2 face="sans-serif"><br>
  > </font>
  > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John
  > Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----</font>
  > <br>
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>Vlad
  > Trakhtenberg/CanWest/IBM@IBMCA</b>
  > </font>
  > <br><font size=1 face="sans-serif">Sent by: www-forms-request@w3.org</font>
  > <p><font size=1 face="sans-serif">08/04/2007 12:00 PM</font>
  > <td width=59%>
  > <table width=100%>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">To</font></div>
  > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">cc</font></div>
  > <td><font size=1 face="sans-serif">www-forms@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">Subject</font></div>
  > <td><font size=1 face="sans-serif">when and how readonly MIP prevents data
  > mutations</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><font size=2 face="sans-serif"><br>
  > Dear WG & Editor,</font><font size=3> <br>
  > </font><font size=2 face="sans-serif"><br>
  > I think the XForms <b>readonly</b> model item property is not defined in
  > clear enough terms, esp. from the implementer's perspective. This lack
  > of clarity persists in the current XForms 1.1 draft. The section <b>6.1.2</b>
  > says: </font>
  > <p><font size=3 face="sans-serif">Description: describes whether the
  > <i>value</i>
  > (!) is restricted from changing. (*)</font><font size=2
  face="sans-serif"><br>
  >          ...<br>
  > Then it follows:</font><font size=3> </font>
  > <p><font size=3 face="sans-serif">When evaluating to true, this model item
  > property indicates that the XForms Processor should not allow <i>any</i>
  > (!) changes to the bound instance data node. (**)</font><font size=3> </font>
  > <p><font size=3 face="sans-serif"><i>In addition</i> to restricting
  <i>value</i>
  > changes, the readonly model item property provides a hint to the XForms
  > user interface. Form controls bound to instance data with the readonly
  > model item property should indicate that entering or changing the value
  > is not allowed.(***)</font><font size=3> <br>
  > <br>
  > </font><font size=2 face="sans-serif"><br>
  > 1. Let's assume for a moment that an implementer should interpret (**)
  > literally, this would mean that all <b>calculate</b> properties shall by
  > default fail to change their respective instance nodes since for all the
  > said nodes the <b>readonly</b> property will evaluate to true() by
  > default.</font><font size=3>
  > </font><font size=2 face="sans-serif"><br>
  > 2.  Again assuming that the readonly node is totally immutable suggests
  > that there are omissions or in the sections of the draft describing
  processing
  > of the <b>insert</b>, <b>delete</b>, <b>setvalue</b>, and <b>reset
  </b>actions
  > as well as submissions with <b>replace</b>="instance" or
  > "text".
  > Notably, there is no defined response if an attempt is made to change
  'readonly'
  > node by these means. <br>
  > 3. A side issue with </font><font size=3 face="sans-serif">(**)</font><font
  > size=2 face="sans-serif">
  > is that if an application is to use instance document  via exposed
  > DOM interfaces </font><font size=3>[getInstanceDocument()] </font><font
  size=2
  > face="sans-serif">it
  > is expected to use DOM methods to possibly mutate it (that's why the
  rebuild(),
  > etc are for) and since there is no DOM access to MIPs there is no way the
  > application can honour the 'no-changes-to-readonly-nodes' rule.</font><font
  > size=3>
  > <br>
  > </font><font size=2 face="sans-serif"><br>
  > To sum it up, I can clearly see how useful and mostly straight forward
  > (with the possible exception of 'readonly' trigger & submit.) is the
  > application of the <b>readonly</b> property by Form controls (as in ***)
  > However, in my opinion, the use of this property to restrict data mutations
  > by other means is either misplaced or underspec'd.</font><font size=3>
  > <br>
  > </font><font size=2 face="sans-serif"><br>
  > Best regards,</font><font size=3> </font><font size=2 face="sans-serif"><br>
  > Vlad Trakhtenberg</font><font size=3> </font><font size=2
  face="sans-serif"><br>
  >  </font><font size=3> </font>
  > --=_alternative 001AF15688257331_=--
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Vlad,
  
  The working group agrees that the applicability of readonly is underspecified.
  The working group decided that readonly is an inviolate property of the model. 
  This means that form controls cannot modify readonly nodes to which they are
  bound, of course, but it also means that XForms actions and submissions have
  restrictions as well.  Specifically, neither setvalue nor text replacement
  submission can modify a readonly node and neither insert, delete nor instance
  replacement submission can modify a node whose parent is readonly.
  
  The reason for checking the parent node in the case of insert is clear: the node
  could not be readonly until after it is inserted.  In the case of delete and
  instance replacement, the view is that node deletion does not change the node. 
  However, node insertion or deletion (and hence replacement) does change the
  *conten* or attribute axis of the parent, which is what readonly is intended to
  protect.
  
  The editor's draft available from the working group page has been updated to
  reflect these substantive changes to XForms 1.1.  Please let us know if you have
  any further concerns regarding the changes made.
  
  Thanks,
  John Boyer
  
  > This is a multipart message in MIME format.
  > --=_alternative 001AF15688257331_=
  > Content-Type: text/plain; charset="US-ASCII"
  > 
  > ----- Forwarded by John Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----
  > 
  > Vlad Trakhtenberg/CanWest/IBM@IBMCA 
  > Sent by: www-forms-request@w3.org
  > 08/04/2007 12:00 PM
  > 
  > To
  > www-forms-editor@w3.org
  > cc
  > www-forms@w3.org
  > Subject
  > when and how readonly MIP prevents data mutations
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > Dear WG & Editor, 
  > 
  > I think the XForms readonly model item property is not defined in clear 
  > enough terms, esp. from the implementer's perspective. This lack of 
  > clarity persists in the current XForms 1.1 draft. The section 6.1.2 says: 
  > Description: describes whether the value (!) is restricted from changing. 
  > (*)
  >          ...
  > Then it follows: 
  > When evaluating to true, this model item property indicates that the 
  > XForms Processor should not allow any (!) changes to the bound instance 
  > data node. (**) 
  > In addition to restricting value changes, the readonly model item property 
  > provides a hint to the XForms user interface. Form controls bound to 
  > instance data with the readonly model item property should indicate that 
  > entering or changing the value is not allowed.(***) 
  > 
  > 
  > 1. Let's assume for a moment that an implementer should interpret (**) 
  > literally, this would mean that all calculate properties shall by default 
  > fail to change their respective instance nodes since for all the said 
  > nodes the readonly property will evaluate to true() by default. 
  > 2.  Again assuming that the readonly node is totally immutable suggests 
  > that there are omissions or in the sections of the draft describing 
  > processing of the insert, delete, setvalue, and reset actions as well as 
  > submissions with replace="instance" or "text". Notably, there is no 
  > defined response if an attempt is made to change 'readonly' node by these 
  > means. 
  > 3. A side issue with (**) is that if an application is to use instance 
  > document  via exposed DOM interfaces [getInstanceDocument()] it is 
  > expected to use DOM methods to possibly mutate it (that's why the 
  > rebuild(), etc are for) and since there is no DOM access to MIPs there is 
  > no way the application can honour the 'no-changes-to-readonly-nodes' rule. 
  > 
  > 
  > To sum it up, I can clearly see how useful and mostly straight forward 
  > (with the possible exception of 'readonly' trigger & submit.) is the 
  > application of the readonly property by Form controls (as in ***) However, 
  > in my opinion, the use of this property to restrict data mutations by 
  > other means is either misplaced or underspec'd. 
  > 
  > Best regards, 
  > Vlad Trakhtenberg 
  >   
  > --=_alternative 001AF15688257331_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <br><font size=2 face="sans-serif"><br>
  > </font>
  > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John
  > Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----</font>
  > <br>
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>Vlad
  > Trakhtenberg/CanWest/IBM@IBMCA</b>
  > </font>
  > <br><font size=1 face="sans-serif">Sent by: www-forms-request@w3.org</font>
  > <p><font size=1 face="sans-serif">08/04/2007 12:00 PM</font>
  > <td width=59%>
  > <table width=100%>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">To</font></div>
  > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">cc</font></div>
  > <td><font size=1 face="sans-serif">www-forms@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">Subject</font></div>
  > <td><font size=1 face="sans-serif">when and how readonly MIP prevents data
  > mutations</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><font size=2 face="sans-serif"><br>
  > Dear WG & Editor,</font><font size=3> <br>
  > </font><font size=2 face="sans-serif"><br>
  > I think the XForms <b>readonly</b> model item property is not defined in
  > clear enough terms, esp. from the implementer's perspective. This lack
  > of clarity persists in the current XForms 1.1 draft. The section <b>6.1.2</b>
  > says: </font>
  > <p><font size=3 face="sans-serif">Description: describes whether the
  > <i>value</i>
  > (!) is restricted from changing. (*)</font><font size=2
  face="sans-serif"><br>
  >          ...<br>
  > Then it follows:</font><font size=3> </font>
  > <p><font size=3 face="sans-serif">When evaluating to true, this model item
  > property indicates that the XForms Processor should not allow <i>any</i>
  > (!) changes to the bound instance data node. (**)</font><font size=3> </font>
  > <p><font size=3 face="sans-serif"><i>In addition</i> to restricting
  <i>value</i>
  > changes, the readonly model item property provides a hint to the XForms
  > user interface. Form controls bound to instance data with the readonly
  > model item property should indicate that entering or changing the value
  > is not allowed.(***)</font><font size=3> <br>
  > <br>
  > </font><font size=2 face="sans-serif"><br>
  > 1. Let's assume for a moment that an implementer should interpret (**)
  > literally, this would mean that all <b>calculate</b> properties shall by
  > default fail to change their respective instance nodes since for all the
  > said nodes the <b>readonly</b> property will evaluate to true() by
  > default.</font><font size=3>
  > </font><font size=2 face="sans-serif"><br>
  > 2.  Again assuming that the readonly node is totally immutable suggests
  > that there are omissions or in the sections of the draft describing
  processing
  > of the <b>insert</b>, <b>delete</b>, <b>setvalue</b>, and <b>reset
  </b>actions
  > as well as submissions with <b>replace</b>="instance" or
  > "text".
  > Notably, there is no defined response if an attempt is made to change
  'readonly'
  > node by these means. <br>
  > 3. A side issue with </font><font size=3 face="sans-serif">(**)</font><font
  > size=2 face="sans-serif">
  > is that if an application is to use instance document  via exposed
  > DOM interfaces </font><font size=3>[getInstanceDocument()] </font><font
  size=2
  > face="sans-serif">it
  > is expected to use DOM methods to possibly mutate it (that's why the
  rebuild(),
  > etc are for) and since there is no DOM access to MIPs there is no way the
  > application can honour the 'no-changes-to-readonly-nodes' rule.</font><font
  > size=3>
  > <br>
  > </font><font size=2 face="sans-serif"><br>
  > To sum it up, I can clearly see how useful and mostly straight forward
  > (with the possible exception of 'readonly' trigger & submit.) is the
  > application of the <b>readonly</b> property by Form controls (as in ***)
  > However, in my opinion, the use of this property to restrict data mutations
  > by other means is either misplaced or underspec'd.</font><font size=3>
  > <br>
  > </font><font size=2 face="sans-serif"><br>
  > Best regards,</font><font size=3> </font><font size=2 face="sans-serif"><br>
  > Vlad Trakhtenberg</font><font size=3> </font><font size=2
  face="sans-serif"><br>
  >  </font><font size=3> </font>
  > --=_alternative 001AF15688257331_=--
  > 
  > 

7.3 Structural schema validation and datatype validation of first text node

PROBLEM ID: 82

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree

NOTES:

  This issue is only substantive in the sense that it documents a change of
  implementation practice that was necessitated by the untenability of the prior
  'first text node' approach, as documented in the notes below.  We do not expect
  an objection as this change was made in response not only to this LC comment but
  numerous community implementation reports of difficulties with the prior
  approach.
  
  For part 1, the spec currently says in revalidate (section 4) that validation
  of
  all instance data occurs, not just datatype node, so we don't believe the spec
  implies that structural validation
  never occurs.
  
  For part 2, you identified a disconnect between schema validation and the first
  text node choice made by UI controls (8.1.1) and setvalue action (section 10). 
  But the real problem is the choice made in UI controls and setvalue, both of
  which should just bind to the content of the referenced node.  UI controls
  already having data binding exception if not bound to simpletype content, and
  setvalue should produce the same exception.
  
  Examples:
  <b></b> has no first text node child in xpath data model
  <b>1<!-- -->A</b> would show '1' to the user but be schema
  invalid as integer
  content
  
  In short, the UI bindings should bind to the content of the referenced node,
  not
  its first text node child for consistency.

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  If I understand sections "4.3.5 The xforms-revalidate Event" and
  "6.1.1 The type Property" of XForms 1.1, XForms only considers
  datatypes during revalidation.
  
  A few questions then:
  
  1. Does this mean that in XForms, we never perform full structural
       validation, even before submission? If so, where is this specified?
  
  2. 6.1.1 says "The type model item property is not applied to instance
       nodes that contain child elements.". However, controls bound to
       elements store and retrieve data as the first child text node of
       the element, see 8.1.1:
  
         "returns the string-value of the first text child node"
  
       and 10.8:
  
         "the first text node is replaced with one corresponding to the
          new value"
  
       Wouldn't it make sense, for consistency, to say that type
       validation applies to the first child text node (empty string if
       none) of an element?
  
       I don't have a very strong opinion on this. Maybe doing so would
       violate expectations of schema validation? But here, we are only
       using datatypes to validate captured data, not validating
       structure, so I am not sure if this is a concern.
  
       I am wondering if this was considered at all.
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Erik,
  
  For part 1, the spec currently says in revalidate (section 4) that validation
  of all instance data occurs, not just datatype node, so we don't believe the
  spec implies that structural validation never occurs.
  
  For part 2, you identified a disconnect between schema validation and the first
  text node choice made by UI controls (8.1.1) and setvalue action (section 10). 
  This has been a long-standing problem that has now been fixed. The real problem
  is the choice made in UI controls and setvalue, both of which should just bind
  to the content of the referenced node.  UI controls already having data binding
  exception if not bound to simpletype content, and setvalue should produce the
  same exception.
  
  There are several problems with binding to the first text node, most notably the
  following:
  
  <a></a> has no first text node child in xpath data model, yet a UI control
  should not fail to bind to a node just because it is empty
  
  <b>1<!-- -->B</b> would show '1' to the user but be schema invalid as integer
  content because 1B is considered
  
  In short, the UI bindings should bind to the content of the referenced node,
  not its first text node child for consistency.
  
  The spec changes needed to implement this behavioral change have been made in
  the editor's draft available from the working group home page.
  
  Best regards,
  John Boyer
  
  > 
  > All,
  > 
  > If I understand sections "4.3.5 The xforms-revalidate Event" and
  > "6.1.1 The type Property" of XForms 1.1, XForms only considers
  > datatypes during revalidation.
  > 
  > A few questions then:
  > 
  > 1. Does this mean that in XForms, we never perform full structural
  >      validation, even before submission? If so, where is this specified?
  > 
  > 2. 6.1.1 says "The type model item property is not applied to instance
  >      nodes that contain child elements.". However, controls bound to
  >      elements store and retrieve data as the first child text node of
  >      the element, see 8.1.1:
  > 
  >        "returns the string-value of the first text child node"
  > 
  >      and 10.8:
  > 
  >        "the first text node is replaced with one corresponding to the
  >         new value"
  > 
  >      Wouldn't it make sense, for consistency, to say that type
  >      validation applies to the first child text node (empty string if
  >      none) of an element?
  > 
  >      I don't have a very strong opinion on this. Maybe doing so would
  >      violate expectations of schema validation? But here, we are only
  >      using datatypes to validate captured data, not validating
  >      structure, so I am not sure if this is a concern.
  > 
  >      I am wondering if this was considered at all.
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

7.4 6.1 Model Item Property Definitions

PROBLEM ID: 100

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#model-xformsconstraints
  
  "It is an error to attempt to set a model item property twice on the same
  node. The details of this process are given at 4.2.1 The
  xforms-model-construct Event.
  (http://www.w3.org/TR/xforms11/#evt-modelConstruct)"
  
  Except that it isn't (has been deleted)
  
  Steven
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The text got moved to rebuild, so an editorial fix will be done.
  
  Thanks,
  The Forms WG
  
  > 
  > http://www.w3.org/TR/xforms11/#model-xformsconstraints
  > 
  > "It is an error to attempt to set a model item property twice on the same
  > node. The details of this process are given at 4.2.1 The
  > xforms-model-construct Event.
  > (http://www.w3.org/TR/xforms11/#evt-modelConstruct)"
  > 
  > Except that it isn't (has been deleted)
  > 
  > Steven
  > 
  > 

7.5 6.1 Model Item Property Definitions

PROBLEM ID: 99

STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#model-xformsconstraints
  
  "It is an error to attempt to set a model item property twice on the same
  node."
  
  I thought we had agreed to relax this. I remember discussing it for
  constraints, but as long as MIPs don't confliuct, is it a problem?
  
  Steven
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Steven,
  
  We did agree to do it in a future version, but not to do it in XForms 1.1. We
  added to the future features.
  
  Best wishes,
  
  Nick Van den Bleeken
  For the Forms WG
  > 
  > http://www.w3.org/TR/xforms11/#model-xformsconstraints
  > 
  > "It is an error to attempt to set a model item property twice on the same
  > node."
  > 
  > I thought we had agreed to relax this. I remember discussing it for
  > constraints, but as long as MIPs don't confliuct, is it a problem?
  > 
  > Steven
  > 
  > 

7.6 [LC: editorial] 6.1.2 The readonly Property

PROBLEM ID: 101

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#model-prop-readOnly
  
  "Default Value: false(), unless a calculate property is specified, then
  true()."
  
  =>
  
  "Default Value: false(), unless a calculate property is specified for the
  value, then true()."
  
  Steven
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  Agreed that we have steadily been improving the spec to ensure that the
  calculate attribute calculates the value property, rather than having a
  calculate property that is somehow distinct from the value of the node being
  calculated.
  
  To that end, your suggestion was accepted but modified to be even clearer.  In
  the editor's draft available from the Forms WG website, it now says "... unless
  a calculate is specified for the value property..."
  
  Therefore, your suggested words have been included.  Please let us know if you
  have any further concerns about this issue.
  
  Thanks,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#model-prop-readOnly
  > 
  > "Default Value: false(), unless a calculate property is specified, then
  > true()."
  > 
  > =>
  > 
  > "Default Value: false(), unless a calculate property is specified for the
  > value, then true()."
  > 
  > Steven
  > 
  > 

7.7 Last call comment about readonly property with calculate

PROBLEM ID: 45

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Disagree

ORIGINAL MESSAGE:

  From: "David Landwehr" <david.landwehr@picoforms.com>
  
  
  
  Having the following:
  <xf:model>
    <xf:instance>
      <data xmlns="">value</data>
    </xf:instance>
    <xf:bind nodeset="." readonly="false()" calculate="1"/>
  </xf:model>
  
  It is not spelled out in the specification that it is possible to
  override the default state when it has a calculate on it. The default
  value is true() when the node has a calculate on it. On the other side
  it is not specified that it is not allowed. I think it should not be
  allowed since it is not clear when the value will be recalculated
  because a node cannot take itself as dependent. E.g. an insert or delete
  will recalculate the value even if the user has updated the value (this
  must also happen if an insert happens in another instance). This could
  be a problem for implementation which isolates the creating of
  dependencies between instances.
  
  Best regards,
  David
  

FOLLOWUP 1:

  From: David Landwehr <david.landwehr@picoforms.com>
  
  The decission is not acceptable as I asked for a different resolution. 
  For big forms optimization of the master dependency graph is of great 
  importance and this resolution detroys the general optimization.
  
  I will read the minuts from the f2f to see on what ground my proposal 
  was disregarded and ask for this to be taken into review again.
  
  /David
  
  John Boyer skrev:
  > We agree it was unclear, but we find that calculate merely defaults readonly to
  > true, and that it can be set to false, and that there are use cases, namely
  > default value. We tested the use case and found it works. We changed the note in
  > 4.3.6 [ http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-recalculate]
  > and put an example in MIP for readonly [
  > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#model-prop-readOnly]
  >
  > Please let us know if this resolution is acceptable.
  >
  > Thank you,
  > The Forms Working Group
  >
  >   
  >> Having the following:
  >> <xf:model>
  >>   <xf:instance>
  >>     <data xmlns="">value</data>
  >>   </xf:instance>
  >>   <xf:bind nodeset="." readonly="false()" calculate="1"/>
  >> </xf:model>
  >>
  >> It is not spelled out in the specification that it is possible to
  >> override the default state when it has a calculate on it. The default
  >> value is true() when the node has a calculate on it. On the other side
  >> it is not specified that it is not allowed. I think it should not be
  >> allowed since it is not clear when the value will be recalculated
  >> because a node cannot take itself as dependent. E.g. an insert or delete
  >> will recalculate the value even if the user has updated the value (this
  >> must also happen if an insert happens in another instance). This could
  >> be a problem for implementation which isolates the creating of
  >> dependencies between instances.
  >>
  >> Best regards,
  >> David
  >>
  >>
  >>     
  

FOLLOWUP 2:

  From: David Landwehr <david.landwehr@picoforms.com>
  
  I have read through the minutes and it seems you don't even consider my 
  request. The statement by John "I don't think you can do that kind of 
  isolation." clearly displays the ignorance from which the decissions are 
  made in the working group.
  
  I accept the resolution simply because I give up.
  /David
  
  John Boyer skrev:
  > We agree it was unclear, but we find that calculate merely defaults readonly to
  > true, and that it can be set to false, and that there are use cases, namely
  > default value. We tested the use case and found it works. We changed the note in
  > 4.3.6 [ http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-recalculate]
  > and put an example in MIP for readonly [
  > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#model-prop-readOnly]
  >
  > Please let us know if this resolution is acceptable.
  >
  > Thank you,
  > The Forms Working Group
  >
  >   
  >> Having the following:
  >> <xf:model>
  >>   <xf:instance>
  >>     <data xmlns="">value</data>
  >>   </xf:instance>
  >>   <xf:bind nodeset="." readonly="false()" calculate="1"/>
  >> </xf:model>
  >>
  >> It is not spelled out in the specification that it is possible to
  >> override the default state when it has a calculate on it. The default
  >> value is true() when the node has a calculate on it. On the other side
  >> it is not specified that it is not allowed. I think it should not be
  >> allowed since it is not clear when the value will be recalculated
  >> because a node cannot take itself as dependent. E.g. an insert or delete
  >> will recalculate the value even if the user has updated the value (this
  >> must also happen if an insert happens in another instance). This could
  >> be a problem for implementation which isolates the creating of
  >> dependencies between instances.
  >>
  >> Best regards,
  >> David
  >>
  >>
  >>     
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  We agree it was unclear, but we find that calculate merely defaults readonly to
  true, and that it can be set to false, and that there are use cases, namely
  default value. We tested the use case and found it works. We changed the note in
  4.3.6 [ http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-recalculate]
  and put an example in MIP for readonly [
  http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#model-prop-readOnly]
  
  Please let us know if this resolution is acceptable.
  
  Thank you,
  The Forms Working Group
  
  > 
  > 
  > Having the following:
  > <xf:model>
  >   <xf:instance>
  >     <data xmlns="">value</data>
  >   </xf:instance>
  >   <xf:bind nodeset="." readonly="false()" calculate="1"/>
  > </xf:model>
  > 
  > It is not spelled out in the specification that it is possible to
  > override the default state when it has a calculate on it. The default
  > value is true() when the node has a calculate on it. On the other side
  > it is not specified that it is not allowed. I think it should not be
  > allowed since it is not clear when the value will be recalculated
  > because a node cannot take itself as dependent. E.g. an insert or delete
  > will recalculate the value even if the user has updated the value (this
  > must also happen if an insert happens in another instance). This could
  > be a problem for implementation which isolates the creating of
  > dependencies between instances.
  > 
  > Best regards,
  > David
  > 
  > 

8. Misc

8.1 [LC] General remarks: Attributes

PROBLEM ID: 53

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  Everywhere an attribute is marked Optional, please say what the
  default value is.
  
  Please say everywhere what the type of attributes are. For instance
  instance@resource. Please list the possible values when they are of an
  enumeration.
  
  Please say everywhere if an XPath expression is required to evaluate
  to a particula type (eg insert@at must be a number or integer).
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Dear Steven,
  
  The editor's draft available from the working group home page now contains
  corrections to address this last call issue.
  
  The enumerations and datatypes of attributes appear in the content model tables
  at the beginnings of the chapters.  In the cases of XPath expression results,
  the expected return type was identified (e.g. string, numeric).  The bulk of the
  issues here seemed to be in Chapter 10 Actions.
  
  The default values for optional attributes are now also identified.  Most
  already were, but the bulk of the issues seemed to arise in Chapter 11
  Submissions for attributes that were analogous to those found in XSLT.
  
  Please let us know if you have any further concerns about this issue.
  
  Thanks,
  John Boyer
  
  > 
  > Everywhere an attribute is marked Optional, please say what the
  > default value is.
  > 
  > Please say everywhere what the type of attributes are. For instance
  > instance@resource. Please list the possible values when they are of an
  > enumeration.
  > 
  > Please say everywhere if an XPath expression is required to evaluate
  > to a particula type (eg insert@at must be a number or integer).
  > 
  > 
  > 

8.2 ITS Rule file

PROBLEM ID: 119

STATE: Suspended
EDIT: None
RESOLUTION: Defer
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Yves Savourel" <ysavourel@translate.com>
  
  --- 1) Is the WG planning to provide an ITS Rule file along with the  
  specification (e.g. as a non-normative appendix)?
  
  [[ Just in case if you are not familiar with ITS: It is a Proposed  
  Recommendation (planning to go as Recommendation next week) that
  define a set of elements and attributes that provide "read-to-go"  
  internationalization features. See also: http://www.w3.org/TR/its/
  ]]
  
  For instance, when I look at the second XML code sample in section 2.1, I  
  see several elements containing text: <label> and <value>.
  Most, if not all, localization tools, as well as ITS, assume element  
  content is translatable. However in this case I'm guessing that
  <value>Cash</Cash> is not.
  
  While this is fine because tools have ways to specify an element should  
  not be translated, it is very often quite difficult no know
  *which elements* is like that. Having a list of elements that are  
  non-translatable (or conversely if there are more non-translatable
  than translatable elements) would help a lot.
  
  This list could be expressed using ITS rules. This way all user of  
  translation tools (or other language-related applications such as
  spell-checker, machine-translation engines, etc) could look up that set of  
  rules and process accordingly. In this example it would
  be as simple as:
  
  <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
    <its:translateRule selector="//value" translate="no"/>
  </its:rules>
  

FOLLOWUP 1:

  From: "Yves Savourel" <ysavourel@translate.com>
  
  Hi Ulrich,
  
  > An ITS rule file is not a normative part of the recommendation 
  > and we would be happy to provide some meeting time to help 
  > I18N WG create it, but we do not have the resources to create it.
  
  We will try to find the time to do it and get back to you to see if what we did make sense.
  
  One question: Do you have a set of XForm files we could use to test it? Something that covers as many of the Xform
  elements/attributes as possible would be ideal.
  
  Thanks
  -yves
  
   
  
  -----Original Message-----
  From: Ulrich Nicolas Lissé [mailto:xforms-issues@mn.aptest.com] 
  Sent: Wednesday, June 13, 2007 2:25 PM
  To: ysavourel@translate.com
  Cc: www-forms-editor@w3.org
  Subject: Re: ITS Rule file (PR#119)
  
  > --- 1) Is the WG planning to provide an ITS Rule file along with the 
  > specification (e.g. as a non-normative appendix)?
  > 
  > [[ Just in case if you are not familiar with ITS: It is a Proposed 
  > Recommendation (planning to go as Recommendation next week) that 
  > define a set of elements and attributes that provide "read-to-go"
  > internationalization features. See also: http://www.w3.org/TR/its/ ]]
  > 
  > For instance, when I look at the second XML code sample in section 
  > 2.1, I see several elements containing text: <label> and <value>.
  > Most, if not all, localization tools, as well as ITS, assume element 
  > content is translatable. However in this case I'm guessing that 
  > <value>Cash</Cash> is not.
  > 
  > While this is fine because tools have ways to specify an element 
  > should not be translated, it is very often quite difficult no know 
  > *which elements* is like that. Having a list of elements that are 
  > non-translatable (or conversely if there are more non-translatable 
  > than translatable elements) would help a lot.
  > 
  > This list could be expressed using ITS rules. This way all user of 
  > translation tools (or other language-related applications such as 
  > spell-checker, machine-translation engines, etc) could look up that 
  > set of rules and process accordingly. In this example it would be as 
  > simple as:
  > 
  > <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
  >   <its:translateRule selector="//value" translate="no"/> </its:rules>
  > 
  > 
  
  An ITS rule file is not a normative part of the recommendation and we would be happy to provide some meeting time to help I18N WG
  create it, but we do not have the resources to create it.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  > --- 1) Is the WG planning to provide an ITS Rule file along with the  
  > specification (e.g. as a non-normative appendix)?
  > 
  > [[ Just in case if you are not familiar with ITS: It is a Proposed  
  > Recommendation (planning to go as Recommendation next week) that
  > define a set of elements and attributes that provide "read-to-go"  
  > internationalization features. See also: http://www.w3.org/TR/its/
  > ]]
  > 
  > For instance, when I look at the second XML code sample in section 2.1, I  
  > see several elements containing text: <label> and <value>.
  > Most, if not all, localization tools, as well as ITS, assume element  
  > content is translatable. However in this case I'm guessing that
  > <value>Cash</Cash> is not.
  > 
  > While this is fine because tools have ways to specify an element should  
  > not be translated, it is very often quite difficult no know
  > *which elements* is like that. Having a list of elements that are  
  > non-translatable (or conversely if there are more non-translatable
  > than translatable elements) would help a lot.
  > 
  > This list could be expressed using ITS rules. This way all user of  
  > translation tools (or other language-related applications such as
  > spell-checker, machine-translation engines, etc) could look up that set of  
  > rules and process accordingly. In this example it would
  > be as simple as:
  > 
  > <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
  >   <its:translateRule selector="//value" translate="no"/>
  > </its:rules>
  > 
  > 
  
  An ITS rule file is not a normative part of the recommendation and we would be
  happy to provide some meeting time to help I18N WG create it, but we do not have
  the resources to create it.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG

8.3 Fw: Add optional root element to schema to encourage SoC

PROBLEM ID: 171

STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: No Response

NOTES:

  We will not add a root element to our schema.  One can
  simply define one's own envelope element in any namespace except ours,
  and that element becomes a mini-host language.

ORIGINAL MESSAGE:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 006D01A788257329_=
  Content-Type: text/plain; charset="US-ASCII"
  
  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
  
  
  ----- Forwarded by John Boyer/CanWest/IBM on 07/31/2007 12:49 PM -----
  
  Guntis Ozols <guntiso@latnet.lv> 
  Sent by: www-forms-editor-request@w3.org
  07/08/2007 04:30 AM
  
  To
  www-forms-editor@w3.org
  cc
  
  Subject
  Add optional root element to schema to encourage SoC
  
  
  
  
  
  
  
  Xml requires root element and xforms schema does not define any,
  thus encouraging to tangle form with host language.
  
  At the moment, xforms are otherwise quite self sufficient.
  
  With root element, forms could be built, tested,
  and stored as valid xml without any irrelevant host language,
  then combined with separately managed host language
  representation(s) (styles) for these forms.
  
  PS. Please refer me to convincing info why keep current
        restriction if I do not know what I am talking about.
  
  Guntis
  
  
  
  --=_alternative 006D01A788257329_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br>
  STSM: Lotus Forms Architect and Researcher<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>
  <br>
  </font>
  <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John
  Boyer/CanWest/IBM on 07/31/2007 12:49 PM -----</font>
  <br>
  <table width=100%>
  <tr valign=top>
  <td width=40%><font size=1 face="sans-serif"><b>Guntis Ozols &lt;guntiso@latnet.lv&gt;</b>
  </font>
  <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font>
  <p><font size=1 face="sans-serif">07/08/2007 04:30 AM</font>
  <td width=59%>
  <table width=100%>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">To</font></div>
  <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">cc</font></div>
  <td>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">Subject</font></div>
  <td><font size=1 face="sans-serif">Add optional root element to schema
  to encourage SoC</font></table>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br>
  <br>
  <br><tt><font size=2><br>
  Xml requires root element and xforms schema does not define any,<br>
  thus encouraging to tangle form with host language.<br>
  <br>
  At the moment, xforms are otherwise quite self sufficient.<br>
  <br>
  With root element, forms could be built, tested,<br>
  and stored as valid xml without any irrelevant host language,<br>
  then combined with separately managed host language<br>
  representation(s) (styles) for these forms.<br>
  <br>
  PS. Please refer me to convincing info why keep current<br>
   &nbsp; &nbsp; &nbsp;restriction if I do not know what I am talking about.<br>
  <br>
  Guntis<br>
  <br>
  <br>
  </font></tt>
  --=_alternative 006D01A788257329_=--
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Hi Guntis,
  
  We will not add a root element to our schema.  One can
  simply define one's own envelope element in any namespace except ours,
  and that element becomes a mini-host language.
  
  Regards,
  
  Nick Van den Bleeken
  
  
  > This is a multipart message in MIME format.
  > --=_alternative 006D01A788257329_=
  > Content-Type: text/plain; charset="US-ASCII"
  > 
  > 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
  > 
  > 
  > ----- Forwarded by John Boyer/CanWest/IBM on 07/31/2007 12:49 PM -----
  > 
  > Guntis Ozols <guntiso@latnet.lv> 
  > Sent by: www-forms-editor-request@w3.org
  > 07/08/2007 04:30 AM
  > 
  > To
  > www-forms-editor@w3.org
  > cc
  > 
  > Subject
  > Add optional root element to schema to encourage SoC
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > Xml requires root element and xforms schema does not define any,
  > thus encouraging to tangle form with host language.
  > 
  > At the moment, xforms are otherwise quite self sufficient.
  > 
  > With root element, forms could be built, tested,
  > and stored as valid xml without any irrelevant host language,
  > then combined with separately managed host language
  > representation(s) (styles) for these forms.
  > 
  > PS. Please refer me to convincing info why keep current
  >       restriction if I do not know what I am talking about.
  > 
  > Guntis
  > 
  > 
  > 
  > --=_alternative 006D01A788257329_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br>
  > STSM: Lotus Forms Architect and Researcher<br>
  > Chair, W3C Forms Working Group<br>
  > Workplace, Portal and Collaboration Software<br>
  > IBM Victoria Software Lab<br>
  > E-Mail: boyerj@ca.ibm.com  <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>
  > <br>
  > </font>
  > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John
  > Boyer/CanWest/IBM on 07/31/2007 12:49 PM -----</font>
  > <br>
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>Guntis Ozols
  > <guntiso@latnet.lv></b>
  > </font>
  > <br><font size=1 face="sans-serif">Sent by:
  > www-forms-editor-request@w3.org</font>
  > <p><font size=1 face="sans-serif">07/08/2007 04:30 AM</font>
  > <td width=59%>
  > <table width=100%>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">To</font></div>
  > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">cc</font></div>
  > <td>
  > <tr valign=top>
  > <td>
  > <div align=right><font size=1 face="sans-serif">Subject</font></div>
  > <td><font size=1 face="sans-serif">Add optional root element to schema
  > to encourage SoC</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><tt><font size=2><br>
  > Xml requires root element and xforms schema does not define any,<br>
  > thus encouraging to tangle form with host language.<br>
  > <br>
  > At the moment, xforms are otherwise quite self sufficient.<br>
  > <br>
  > With root element, forms could be built, tested,<br>
  > and stored as valid xml without any irrelevant host language,<br>
  > then combined with separately managed host language<br>
  > representation(s) (styles) for these forms.<br>
  > <br>
  > PS. Please refer me to convincing info why keep current<br>
  >       restriction if I do not know what I am talking about.<br>
  > <br>
  > Guntis<br>
  > <br>
  > <br>
  > </font></tt>
  > --=_alternative 006D01A788257329_=--
  > 
  > 

8.4 CDF02 - Abstract (moved to Introduction) missing reference to compound documents.

PROBLEM ID: 125

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree

NOTES:

  Initial response said "1) This is only a working draft whose advancement we
  don't want to be tied to; and 2) XForms is intended to be used with host
  languages even if they do not observe the compound document framework."
  The CDF group responded that they only wanted an informative reference to CDRF
  because it contained the definition of compound document, so the reference was
  added.

ORIGINAL MESSAGE:

  From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com>
  
  Change
  "XForms is not a free-standing document type, but is intended to be
  integrated into other markup languages, "
  To
  "XForms is not a free-standing document type, but is intended to be
  integrated into other markup languages as a compound document [see CDRF 1.0
  ]. "
  Add to Appendix B References
  "CDRF 1.0
         Compound Document by Reference Framework 1.0, Timur Mehrvarz, Lasse
  Pajunen, Julien Quint, Daniel Applequist,
  2007, W3C Working Draft available at http://www.w3.org/TR/CDR/"
  Rationale: Compound Document is the W3C term for a document that combines
  multiple formats.
  

FOLLOWUP 1:

  From: member-cdf-request@w3.org
  
  *** NOTE: ***
  
      Your message was sent from an address which is not on the list
      of people who are authorized to post to this mailing list.
      Therefore, your message has been forwarded to the list maintainer
      for manual processing.
  
      If you do not see your message appear on the list or in the
      mailing list archives within a few business days, you may wish
      to contact the mailing list maintainer to investigate the delay.
  
      -- W3C Postmaster
         http://www.w3.org/Mail/
  
  your message follows:
  ----------------------------------------------------------------------------
  
  
  Dear CDF WG,
  
  1) This is only a working draft whose advancement we don't want to be tied to.
  2) XForms is intended to be used with host languages even if they do not
  observe
  the compound document framework.
  
  Regards,
  Nick Van den Bleeken
  
  > Change
  > "XForms is not a free-standing document type, but is intended to be
  > integrated into other markup languages, "
  > To
  > "XForms is not a free-standing document type, but is intended to be
  > integrated into other markup languages as a compound document [see CDRF 1.0
  > ]. "
  > Add to Appendix B References
  > "CDRF 1.0
  >        Compound Document by Reference Framework 1.0, Timur Mehrvarz, Lasse
  > Pajunen, Julien Quint, Daniel Applequist,
  > 2007, W3C Working Draft available at http://www.w3.org/TR/CDR/"
  > Rationale: Compound Document is the W3C term for a document that combines
  > multiple formats.
  > 
  > 
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear CDF WG,
  
  1) This is only a working draft whose advancement we don't want to be tied to.
  2) XForms is intended to be used with host languages even if they do not
  observe
  the compound document framework.
  
  Regards,
  Nick Van den Bleeken
  
  > Change
  > "XForms is not a free-standing document type, but is intended to be
  > integrated into other markup languages, "
  > To
  > "XForms is not a free-standing document type, but is intended to be
  > integrated into other markup languages as a compound document [see CDRF 1.0
  > ]. "
  > Add to Appendix B References
  > "CDRF 1.0
  >        Compound Document by Reference Framework 1.0, Timur Mehrvarz, Lasse
  > Pajunen, Julien Quint, Daniel Applequist,
  > 2007, W3C Working Draft available at http://www.w3.org/TR/CDR/"
  > Rationale: Compound Document is the W3C term for a document that combines
  > multiple formats.
  > 
  > 

8.5 CDF03 - Abstract (Moved to Introduction) missing reference to ODF.

PROBLEM ID: 126

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response

NOTES:

  We agreed to add ODF as example and to add an informative reference. 

ORIGINAL MESSAGE:

  From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com>
  
  
  Change
  "such as XHTML or SVG. "
  To
  "such as XHTML, ODF [see ODF 1.1], or SVG. "
  Add to references
  "ODF 1.1
         Open Document Format for Office Applications (OpenDocument) v1.1,
  Patrick Durusau, Micheal Brauer, Lars Oppermann, 2007, available at
  http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#odf11
  Rationale: No where in the XForms 1.1 does it state that XForms must be
  included in whole.  ODF uses some XForms elements and is an open standard
  so it should be acknowledged as a non-W3C example of using XForms as a
  compound document.
  

FOLLOWUP 1:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 005E0DE688257384_=
  Content-Type: text/plain; charset="US-ASCII"
  
  Hi Kevin,
  
  An informative reference for ODF 1.1 has been added to the XForms 1.1 
  specification.  Please see the editor's draft available from the Forms WG 
  homepage.
  
  Best regards,
  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
  
  
  --=_alternative 005E0DE688257384_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <br><font size=2 face="sans-serif">Hi Kevin,</font>
  <br>
  <br><font size=2 face="sans-serif">An informative reference for ODF 1.1
  has been added to the XForms 1.1 specification. &nbsp;Please see the editor's
  draft available from the Forms WG homepage.</font>
  <br>
  <br><font size=2 face="sans-serif">Best regards,</font>
  <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br>
  STSM: Lotus Forms Architect and Researcher<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>
  <br>
  </font>
  --=_alternative 005E0DE688257384_=--
  

FOLLOWUP 2:

  From: Kevin E Kelly <Kevin.Kelly@us.ibm.com>
  
  --0__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593
  Content-type: multipart/alternative; 
  	Boundary="1__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593"
  
  --1__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593
  Content-type: text/plain; charset=US-ASCII
  Content-transfer-encoding: quoted-printable
  
  
  XForms WG:
  
  We find this a little confusing.  You do already have references for XH=
  TML
  and SVG in your document, and you have both normative and informative
  references sections.  Why not link ODF in the informative section?
  
  ALSO - Nick your emails to the member-cdf WG did not arrive to that mai=
  l
  list.  Would you please resend them to member-cdf@w3.org from another e=
  mail
  address that is not blocked?
  
  CDF WG
  
  
  
                                                                         =
                                                                    
    From:       Nick Van den Bleeken <xforms-issues@mn.aptest.com>       =
                                                                    
                                                                         =
                                                                    
    To:         Kevin E Kelly/Raleigh/IBM@IBMUS                          =
                                                                    
                                                                         =
                                                                    
    Cc:         member-cdf@w3.org, www-forms-editor@w3.org               =
                                                                    
                                                                         =
                                                                    
    Date:       09/12/2007 06:45 AM                                      =
                                                                    
                                                                         =
                                                                    
    Subject:    Re: CDF03 - Abstract (Moved to Introduction) missing refe=
  rence to ODF. (PR#126)                                            
                                                                         =
                                                                    
  
  
  
  
  
  Dear CDF WG,
  
  We agreed to add ODF as example but are not going to reference ODF, bec=
  ause
  we
  don't reference XHTML nor SVG.
  
  Regards,
  
  Nick Van den Bleeken
  >
  > Change
  > "such as XHTML or SVG. "
  > To
  > "such as XHTML, ODF [see ODF 1.1], or SVG. "
  > Add to references
  > "ODF 1.1
  >        Open Document Format for Office Applications (OpenDocument) v1=
  .1,
  > Patrick Durusau, Micheal Brauer, Lars Oppermann, 2007, available at
  > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Doffice#o=
  df11
  > Rationale: No where in the XForms 1.1 does it state that XForms must =
  be
  > included in whole.  ODF uses some XForms elements and is an open stan=
  dard
  > so it should be acknowledged as a non-W3C example of using XForms as =
  a
  > compound document.
  >
  >
  =
  
  --1__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593
  Content-type: text/html; charset=US-ASCII
  Content-Disposition: inline
  Content-transfer-encoding: quoted-printable
  
  <html><body>
  <p>XForms WG:<br>
  <br>
  We find this a little confusing.  You do already have references for XH=
  TML and SVG in your document, and you have both normative and informati=
  ve references sections.  Why not link ODF in the informative section? <=
  br>
  <br>
  ALSO - Nick your emails to the member-cdf WG did not arrive to that mai=
  l list.  Would you please resend them to member-cdf@w3.org from another=
   email address that is not blocked?<br>
  <br>
  CDF WG<br>
  <br>
  <br>
  <img width=3D"16" height=3D"16" src=3D"cid:1__=3D0ABBF9F2DFD575938f9e8a=
  93df938@us.ibm.com" border=3D"0" alt=3D"Inactive hide details for Nick =
  Van den Bleeken ---09/12/2007 06:45:32 AM---Dear CDF WG,"><font color=3D=
  "#424282">Nick Van den Bleeken ---09/12/2007 06:45:32 AM---Dear CDF WG,=
  </font><br>
  <br>
  
  <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=
  
  <tr valign=3D"top"><td width=3D"1%"><img width=3D"96" height=3D"1" src=3D=
  "cid:2__=3D0ABBF9F2DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
  ""><br>
  <font size=3D"2" color=3D"#5F5F5F">From:</font></td><td width=3D"100%">=
  <img width=3D"1" height=3D"1" src=3D"cid:2__=3D0ABBF9F2DFD575938f9e8a93=
  df938@us.ibm.com" border=3D"0" alt=3D""><br>
  <font size=3D"2">Nick Van den Bleeken &lt;xforms-issues@mn.aptest.com&g=
  t;</font></td></tr>
  
  <tr valign=3D"top"><td width=3D"1%"><img width=3D"96" height=3D"1" src=3D=
  "cid:2__=3D0ABBF9F2DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
  ""><br>
  <font size=3D"2" color=3D"#5F5F5F">To:</font></td><td width=3D"100%"><i=
  mg width=3D"1" height=3D"1" src=3D"cid:2__=3D0ABBF9F2DFD575938f9e8a93df=
  938@us.ibm.com" border=3D"0" alt=3D""><br>
  <font size=3D"2">Kevin E Kelly/Raleigh/IBM@IBMUS</font></td></tr>
  
  <tr valign=3D"top"><td width=3D"1%"><img width=3D"96" height=3D"1" src=3D=
  "cid:2__=3D0ABBF9F2DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
  ""><br>
  <font size=3D"2" color=3D"#5F5F5F">Cc:</font></td><td width=3D"100%" va=
  lign=3D"middle"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D0ABBF9F2=
  DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
  <font size=3D"2">member-cdf@w3.org, www-forms-editor@w3.org</font></td>=
  </tr>
  
  <tr valign=3D"top"><td width=3D"1%"><img width=3D"96" height=3D"1" src=3D=
  "cid:2__=3D0ABBF9F2DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
  ""><br>
  <font size=3D"2" color=3D"#5F5F5F">Date:</font></td><td width=3D"100%">=
  <img width=3D"1" height=3D"1" src=3D"cid:2__=3D0ABBF9F2DFD575938f9e8a93=
  df938@us.ibm.com" border=3D"0" alt=3D""><br>
  <font size=3D"2">09/12/2007 06:45 AM</font></td></tr>
  
  <tr valign=3D"top"><td width=3D"1%"><img width=3D"96" height=3D"1" src=3D=
  "cid:2__=3D0ABBF9F2DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
  ""><br>
  <font size=3D"2" color=3D"#5F5F5F">Subject:</font></td><td width=3D"100=
  %"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D0ABBF9F2DFD575938f9e8=
  a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
  <font size=3D"2">Re: CDF03 - Abstract (Moved to Introduction) missing r=
  eference to ODF. (PR#126)</font></td></tr>
  </table>
  <hr width=3D"100%" size=3D"2" align=3D"left" noshade style=3D"color:#80=
  91A5; "><br>
  <br>
  <br>
  <tt>Dear CDF WG,<br>
  <br>
  We agreed to add ODF as example but are not going to reference ODF, bec=
  ause we<br>
  don't reference XHTML nor SVG. <br>
  <br>
  Regards,<br>
  <br>
  Nick Van den Bleeken<br>
  &gt; <br>
  &gt; Change<br>
  &gt; &quot;such as XHTML or SVG. &quot;<br>
  &gt; To<br>
  &gt; &quot;such as XHTML, ODF [see ODF 1.1], or SVG. &quot;<br>
  &gt; Add to references<br>
  &gt; &quot;ODF 1.1<br>
  &gt; &nbsp; &nbsp; &nbsp; &nbsp;Open Document Format for Office Applica=
  tions (OpenDocument) v1.1,<br>
  &gt; Patrick Durusau, Micheal Brauer, Lars Oppermann, 2007, available a=
  t<br>
  &gt; </tt><tt><a href=3D"http://www.oasis-open.org/committees/tc_home.p=
  hp?wg_abbrev=3Doffice#odf11">http://www.oasis-open.org/committees/tc_ho=
  me.php?wg_abbrev=3Doffice#odf11</a></tt><tt><br>
  &gt; Rationale: No where in the XForms 1.1 does it state that XForms mu=
  st be<br>
  &gt; included in whole. &nbsp;ODF uses some XForms elements and is an o=
  pen standard<br>
  &gt; so it should be acknowledged as a non-W3C example of using XForms =
  as a<br>
  &gt; compound document.<br>
  &gt; <br>
  &gt; <br>
  </tt><br>
  </body></html>=
  
  
  --1__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593--
  
  
  --0__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593
  Content-type: image/gif; 
  	name="graycol.gif"
  Content-Disposition: inline; filename="graycol.gif"
  Content-ID: <1__=0ABBF9F2DFD575938f9e8a93df938@us.ibm.com>
  Content-transfer-encoding: base64
  
  R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
  ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
  
  --0__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593
  Content-type: image/gif; 
  	name="ecblank.gif"
  Content-Disposition: inline; filename="ecblank.gif"
  Content-ID: <2__=0ABBF9F2DFD575938f9e8a93df938@us.ibm.com>
  Content-transfer-encoding: base64
  
  R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7
  
  --0__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593--
  

FOLLOWUP 3:

  From: member-cdf-request@w3.org
  
  *** NOTE: ***
  
      Your message was sent from an address which is not on the list
      of people who are authorized to post to this mailing list.
      Therefore, your message has been forwarded to the list maintainer
      for manual processing.
  
      If you do not see your message appear on the list or in the
      mailing list archives within a few business days, you may wish
      to contact the mailing list maintainer to investigate the delay.
  
      -- W3C Postmaster
         http://www.w3.org/Mail/
  
  your message follows:
  ----------------------------------------------------------------------------
  
  
  Dear CDF WG,
  
  We agreed to add ODF as example but are not going to reference ODF, because we
  don't reference XHTML nor SVG. 
  
  Regards,
  
  Nick Van den Bleeken
  > 
  > Change
  > "such as XHTML or SVG. "
  > To
  > "such as XHTML, ODF [see ODF 1.1], or SVG. "
  > Add to references
  > "ODF 1.1
  >        Open Document Format for Office Applications (OpenDocument) v1.1,
  > Patrick Durusau, Micheal Brauer, Lars Oppermann, 2007, available at
  > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#odf11
  > Rationale: No where in the XForms 1.1 does it state that XForms must be
  > included in whole.  ODF uses some XForms elements and is an open standard
  > so it should be acknowledged as a non-W3C example of using XForms as a
  > compound document.
  > 
  > 
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear CDF WG,
  
  We agreed to add ODF as example but are not going to reference ODF, because we
  don't reference XHTML nor SVG. 
  
  Regards,
  
  Nick Van den Bleeken
  > 
  > Change
  > "such as XHTML or SVG. "
  > To
  > "such as XHTML, ODF [see ODF 1.1], or SVG. "
  > Add to references
  > "ODF 1.1
  >        Open Document Format for Office Applications (OpenDocument) v1.1,
  > Patrick Durusau, Micheal Brauer, Lars Oppermann, 2007, available at
  > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#odf11
  > Rationale: No where in the XForms 1.1 does it state that XForms must be
  > included in whole.  ODF uses some XForms elements and is an open standard
  > so it should be acknowledged as a non-W3C example of using XForms as a
  > compound document.
  > 
  > 

8.6 [XForms 1.1] i18n comment: Mention of Internationalization

PROBLEM ID: 9

STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: fsasaki@w3.org
  
  
  Comment from the i18n review of:
  http://www.w3.org/TR/2007/WD-xforms11-20070222/
  
  Comment 3
  At http://www.w3.org/International/reviews/0704-xforms11/
  Editorial/substantive: S
  Location in reviewed document:
  2
  Mention of Internationalization
  
  Comment:
  
    Internationalization Using XML 1.0 for instance data ensures that the  
  submitted data is internationalization ready.
    We think that XForms should refer to XML 1.1 as well.
  
  

FOLLOWUP 1:

  From: "Yves Savourel" <ysavourel@translate.com>
  
  Hi Ulrich,
  
  > An ITS rule file is not a normative part of the recommendation 
  > and we would be happy to provide some meeting time to help 
  > I18N WG create it, but we do not have the resources to create it.
  
  We will try to find the time to do it and get back to you to see if what we did make sense.
  
  One question: Do you have a set of XForm files we could use to test it? Something that covers as many of the Xform
  elements/attributes as possible would be ideal.
  
  Thanks
  -yves
  
   
  
  -----Original Message-----
  From: Ulrich Nicolas Lissé [mailto:xforms-issues@mn.aptest.com] 
  Sent: Wednesday, June 13, 2007 2:25 PM
  To: ysavourel@translate.com
  Cc: www-forms-editor@w3.org
  Subject: Re: ITS Rule file (PR#119)
  
  > --- 1) Is the WG planning to provide an ITS Rule file along with the 
  > specification (e.g. as a non-normative appendix)?
  > 
  > [[ Just in case if you are not familiar with ITS: It is a Proposed 
  > Recommendation (planning to go as Recommendation next week) that 
  > define a set of elements and attributes that provide "read-to-go"
  > internationalization features. See also: http://www.w3.org/TR/its/ ]]
  > 
  > For instance, when I look at the second XML code sample in section 
  > 2.1, I see several elements containing text: <label> and <value>.
  > Most, if not all, localization tools, as well as ITS, assume element 
  > content is translatable. However in this case I'm guessing that 
  > <value>Cash</Cash> is not.
  > 
  > While this is fine because tools have ways to specify an element 
  > should not be translated, it is very often quite difficult no know 
  > *which elements* is like that. Having a list of elements that are 
  > non-translatable (or conversely if there are more non-translatable 
  > than translatable elements) would help a lot.
  > 
  > This list could be expressed using ITS rules. This way all user of 
  > translation tools (or other language-related applications such as 
  > spell-checker, machine-translation engines, etc) could look up that 
  > set of rules and process accordingly. In this example it would be as 
  > simple as:
  > 
  > <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
  >   <its:translateRule selector="//value" translate="no"/> </its:rules>
  > 
  > 
  
  An ITS rule file is not a normative part of the recommendation and we would be happy to provide some meeting time to help I18N WG
  create it, but we do not have the resources to create it.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  

FOLLOWUP 2:

  From: Felix Sasaki <fsasaki@w3.org>
  
  Thank you for your reply. I'm satisfied with your resolution. If you 
  don't hear from other participants of the i18n core WG until Wednesday 
  next week (19 Sept), please regard this issue as closed.
  
  Felix
  
  Nick Van den Bleeken wrote:
  > Felix,
  >
  > We defer the support of XML 1.1 to a later version of XForms, because XForms 1.1
  > is based on XPath 1.0 and XPath 1.0 doesn't supports XML 1.1
  >
  > We plan to support XPath 2.0 in XForms 2.0, and could consider supporting XML
  > 1.1 at that time.
  >
  > Regards,
  >
  > Nick Van den Bleeken
  >
  >   
  >> Comment from the i18n review of:
  >> http://www.w3.org/TR/2007/WD-xforms11-20070222/
  >>
  >> Comment 3
  >> At http://www.w3.org/International/reviews/0704-xforms11/
  >> Editorial/substantive: S
  >> Location in reviewed document:
  >> 2
  >> Mention of Internationalization
  >>
  >> Comment:
  >>
  >>   Internationalization Using XML 1.0 for instance data ensures that the  
  >> submitted data is internationalization ready.
  >>   We think that XForms should refer to XML 1.1 as well.
  >>
  >>
  >>
  >>     
  
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  > --- 1) Is the WG planning to provide an ITS Rule file along with the  
  > specification (e.g. as a non-normative appendix)?
  > 
  > [[ Just in case if you are not familiar with ITS: It is a Proposed  
  > Recommendation (planning to go as Recommendation next week) that
  > define a set of elements and attributes that provide "read-to-go"  
  > internationalization features. See also: http://www.w3.org/TR/its/
  > ]]
  > 
  > For instance, when I look at the second XML code sample in section 2.1, I  
  > see several elements containing text: <label> and <value>.
  > Most, if not all, localization tools, as well as ITS, assume element  
  > content is translatable. However in this case I'm guessing that
  > <value>Cash</Cash> is not.
  > 
  > While this is fine because tools have ways to specify an element should  
  > not be translated, it is very often quite difficult no know
  > *which elements* is like that. Having a list of elements that are  
  > non-translatable (or conversely if there are more non-translatable
  > than translatable elements) would help a lot.
  > 
  > This list could be expressed using ITS rules. This way all user of  
  > translation tools (or other language-related applications such as
  > spell-checker, machine-translation engines, etc) could look up that set of  
  > rules and process accordingly. In this example it would
  > be as simple as:
  > 
  > <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
  >   <its:translateRule selector="//value" translate="no"/>
  > </its:rules>
  > 
  > 
  
  An ITS rule file is not a normative part of the recommendation and we would be
  happy to provide some meeting time to help I18N WG create it, but we do not have
  the resources to create it.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG

REPLY 2:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Felix,
  
  We defer the support of XML 1.1 to a later version of XForms, because XForms 1.1
  is based on XPath 1.0 and XPath 1.0 doesn't supports XML 1.1
  
  We plan to support XPath 2.0 in XForms 2.0, and could consider supporting XML
  1.1 at that time.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > Comment from the i18n review of:
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > 
  > Comment 3
  > At http://www.w3.org/International/reviews/0704-xforms11/
  > Editorial/substantive: S
  > Location in reviewed document:
  > 2
  > Mention of Internationalization
  > 
  > Comment:
  > 
  >   Internationalization Using XML 1.0 for instance data ensures that the  
  > submitted data is internationalization ready.
  >   We think that XForms should refer to XML 1.1 as well.
  > 
  > 
  > 

8.7 [LC1.1] Changes from XForms 1.0 and examples

PROBLEM ID: 162

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  We agreed to add a section to 1. About the XForms Specification

ORIGINAL MESSAGE:

  From: "Steve K Speicher" <sspeiche@us.ibm.com>
  
  
  LC comment on http://www.w3.org/TR/2007/WD-xforms11-20070222
  
  1) I struggled to find the differences between 1.0 and 1.1, I guess I was
  expecting a brief intro section like:
  http://www.w3.org/TR/2001/REC-xhtml11-20010531/changes.html#a_changes
  I did find the diff marked version, which was a big help.
  
  Thanks,
  Steve Speicher
  IBM SWG, Software Standards
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Hi Steve,
  
  We will update the spec accordingly, a section will be added that contains the
  improvements made in XForms 1.1 relative to XForms 1.0
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > LC comment on http://www.w3.org/TR/2007/WD-xforms11-20070222
  > 
  > 1) I struggled to find the differences between 1.0 and 1.1, I guess I was
  > expecting a brief intro section like:
  > http://www.w3.org/TR/2001/REC-xhtml11-20010531/changes.html#a_changes
  > I did find the diff marked version, which was a big help.
  > 
  > Thanks,
  > Steve Speicher
  > IBM SWG, Software Standards
  > 
  > 

8.8 Formal Objection: publication of XForms 1.1 as LCWD

PROBLEM ID: 17

STATE: Approved and Implemented
EDIT: None
RESOLUTION: Modify and Accept
USER POSITION: Agree

NOTES:

  The changes needed were already made in XForms 1.0, which were carried forward
  to XForms 1.1.
  
  The objection is based on the fact that we didn't reply to earlier issues. We
  have now done that, see threads at:
    http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0050
    http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0055
    http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0056
  
  No reply from the commentator.
  
  For the record, we don't believe the process allows a formal objection to a
  decision to go to last call. It would have been friendlier if the commentator
  had just said "please be sure to deal with the following issues".

ORIGINAL MESSAGE:

  From: "Bjoern Hoehrmann" <derhoermi@gmx.net>
  
  
  Dear Forms Working Group,
  
     Please report to The Director my formal objection to the Working
  Group's decision to publish XForms 1.1 as Last Call Working Draft.
  The group made this decision in violation of the W3C Process, and due
  to its shocking history of W3C Process ignorance it would be difficult
  to assert that the document has received wide review and, therefore,
  advance the document under the rules of the W3C Process.
  
  Since the Forms Working Group has no interest in following the W3C
  Recommendation Track Process to develop XForms as demonstrated below,
  it is unclear to me that XForms development should continue in form
  of a W3C Working Group.
  
  However, if that is to be so, I recommend that instead of advancing
  XForms 1.1, the document is returned to the Working Group for further
  work and the group does not request publication of it as LCWD until
  after the group has, for all comments received since the publication
  of XForms 1.0 as LCWD, either formally addressed the comment or pub-
  lically documented sound rationale for not doing so, documented the
  results of this process, published updated non-LC drafts taking the
  results of this process into account, given reviewers sufficient time
  to review it, and put the XForms 1.0 errata into a form that satisfies
  the requirements of the W3C Process.
  
  It is important to note that this is not asking anything at all, had
  the Working Group not ignored the W3C Process for many years, this
  would be a zero-effort process. Similarily, the concern is not that
  a few things slipped through the cracks: the group has been repeatedly
  reminded of its failure the follow the W3C Process, and took little to
  no action to improve the situation. To give a few examples of my own
  experience with the group:
  
  Pre-REC comments on XForms 1.0 that I have never received a response to:
  
    http://lists.w3.org/Archives/Public/www-forms-editor/2003Aug/0002.html
    http://lists.w3.org/Archives/Public/www-forms-editor/2003Aug/0003.html
  
  An XForms 1.1 comment the group produced no meaningful response to:
  
    http://lists.w3.org/Archives/Public/www-forms-editor/2004Jan/0004.html
  
  A reminder to address the comment above (more reminders further down):
  
    http://lists.w3.org/Archives/Public/www-forms-editor/2004Aug/0001.html
  
  Discussions of the group's continued Process ignorance:
  
    http://lists.w3.org/Archives/Public/www-forms/2004Oct/0014.html
    http://lists.w3.org/Archives/Public/www-forms/2004Nov/0050.html
  
  A detailed review of how the group systematically ignored 1.0 comments:
  
    http://lists.w3.org/Archives/Member/process-issues/2006Feb/0001.html
  
  Reminders of the W3C Process requirements for errata maintenance:
  
    http://lists.w3.org/Archives/Public/www-forms/2006Jun/0043.html
    http://lists.w3.org/Archives/Public/www-forms/2006Sep/0109.html
  
  The group has not provided a response to any of these messages. As I
  already concluded in 2004, any attempt to cooperate with the group is
  a complete waste of effort. This view is shared, at least in part, by
  several other people with first hand experience with the Forms WG I
  talked to. As a consequence, many interested parties chose to not
  review the XForms 1.1 draft at all, let alone provide comments on it.
  
  Having received wide review is a pre-condition for advancement of the
  document to Candidate Recommendation status, and without the group
  following the the steps proposed above in full, it would be difficult
  to get to a point where interested parties do not actively refuse to
  review the document. Hence my recommendation.
  
  Thanks,
  -- 
  Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
  Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
  68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
  

8.9 [XForms 1.1] i18n comment: Various comments on XForms 1.1

PROBLEM ID: 15

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  This is a duplicate of issues 109 (which was trashed in favour of separate
  issues).
  
  Recommend the following response:
  
  Answers for all last call comments attributed to Yves Savourel are now
  available
  in the www-forms-editor list archive and the results of spec changes now appear
  in the editor's draft available from the Forms WG website.

ORIGINAL MESSAGE:

  From: fsasaki@w3.org
  
  
  Comment from the i18n review of:
  http://www.w3.org/TR/2007/WD-xforms11-20070222/
  
  Comment 10
  At http://www.w3.org/International/reviews/0704-xforms11/
  Editorial/substantive: S
  Location in reviewed document:
  Various
  Various comments on XForms 1.1
  
  Comment:
  The Working Group endorses the coment sent by Yves Savourel
  http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html  
  [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html]
  , especially comment 1 (\"Is the WG planning to provide an ITS Rule file  
  along with the specification (e.g. as a non-normative appendix)?\")  
  Pleasekeep us in the loop during your discussion of the comments.
  
  

FOLLOWUP 1:

  From: "Richard Ishida" <ishida@w3.org>
  
  John,
  
  Could you provide some links please?  A quick look didn't reveal the
  location of the relevant information, and may have missed some important
  bits.
  
  Thanks,
  RI
  
  ============
  Richard Ishida
  Internationalization Lead
  W3C (World Wide Web Consortium)
   
  http://www.w3.org/People/Ishida/
  http://www.w3.org/International/
  http://people.w3.org/rishida/blog/
  http://www.flickr.com/photos/ishida/
   
   
  
  > -----Original Message-----
  > From: www-international-request@w3.org 
  > [mailto:www-international-request@w3.org] On Behalf Of John Boyer
  > Sent: 26 July 2007 19:40
  > To: fsasaki@w3.org
  > Cc: www-forms-editor@w3.org; www-international@w3.org
  > Subject: Re: [XForms 1.1] i18n comment: Various comments on 
  > XForms 1.1 (PR#15)
  > 
  > 
  > Answers for all last call comments attributed to Yves 
  > Savourel are now available in the www-forms-editor list 
  > archive and the results of spec changes now appear in the 
  > editor's draft available from the Forms WG website.
  > 
  > Best regards,
  > John Boyer
  > 
  > > 
  > > Comment from the i18n review of:
  > > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > > 
  > > Comment 10
  > > At http://www.w3.org/International/reviews/0704-xforms11/
  > > Editorial/substantive: S
  > > Location in reviewed document:
  > > Various
  > > Various comments on XForms 1.1
  > > 
  > > Comment:
  > > The Working Group endorses the coment sent by Yves Savourel 
  > > 
  > http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html
  > > 
  > [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.htm
  > > l] , especially comment 1 (\"Is the WG planning to provide 
  > an ITS Rule 
  > > file along with the specification (e.g. as a non-normative 
  > > appendix)?\") Pleasekeep us in the loop during your 
  > discussion of the 
  > > comments.
  > > 
  > > 
  > > 
  > 
  

FOLLOWUP 2:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 0071744D88257329_=
  Content-Type: text/plain; charset="US-ASCII"
  
  http://www.w3.org/Search/Mail/Public/search?keywords=ysavourel&hdr-1-name=subject&hdr-1-query=&index-grp=Public__FULL&index-type=t&type-index=www-forms-editor
  
  Cheers,
  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
  
  
  
  
  
  "Richard Ishida" <ishida@w3.org> 
  Sent by: www-forms-editor-request@w3.org
  07/30/2007 03:38 AM
  
  To
  "'John Boyer'" <xforms-issues@mn.aptest.com>, <fsasaki@w3.org>
  cc
  <www-forms-editor@w3.org>, <www-international@w3.org>
  Subject
  RE: [XForms 1.1] i18n comment: Various comments on XForms 1.1 (PR#15)
  
  
  
  
  
  
  
  John,
  
  Could you provide some links please?  A quick look didn't reveal the
  location of the relevant information, and may have missed some important
  bits.
  
  Thanks,
  RI
  
  ============
  Richard Ishida
  Internationalization Lead
  W3C (World Wide Web Consortium)
   
  http://www.w3.org/People/Ishida/
  http://www.w3.org/International/
  http://people.w3.org/rishida/blog/
  http://www.flickr.com/photos/ishida/
   
   
  
  > -----Original Message-----
  > From: www-international-request@w3.org 
  > [mailto:www-international-request@w3.org] On Behalf Of John Boyer
  > Sent: 26 July 2007 19:40
  > To: fsasaki@w3.org
  > Cc: www-forms-editor@w3.org; www-international@w3.org
  > Subject: Re: [XForms 1.1] i18n comment: Various comments on 
  > XForms 1.1 (PR#15)
  > 
  > 
  > Answers for all last call comments attributed to Yves 
  > Savourel are now available in the www-forms-editor list 
  > archive and the results of spec changes now appear in the 
  > editor's draft available from the Forms WG website.
  > 
  > Best regards,
  > John Boyer
  > 
  > > 
  > > Comment from the i18n review of:
  > > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > > 
  > > Comment 10
  > > At http://www.w3.org/International/reviews/0704-xforms11/
  > > Editorial/substantive: S
  > > Location in reviewed document:
  > > Various
  > > Various comments on XForms 1.1
  > > 
  > > Comment:
  > > The Working Group endorses the coment sent by Yves Savourel 
  > > 
  > http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html
  > > 
  > [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.htm
  > > l] , especially comment 1 (\"Is the WG planning to provide 
  > an ITS Rule 
  > > file along with the specification (e.g. as a non-normative 
  > > appendix)?\") Pleasekeep us in the loop during your 
  > discussion of the 
  > > comments.
  > > 
  > > 
  > > 
  > 
  
  
  
  
  --=_alternative 0071744D88257329_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <br><a href="http://www.w3.org/Search/Mail/Public/search?keywords=ysavourel&amp;hdr-1-name=subject&amp;hdr-1-query=&amp;index-grp=Public__FULL&amp;index-type=t&amp;type-index=www-forms-editor"><font size=2 face="sans-serif">http://www.w3.org/Search/Mail/Public/search?keywords=ysavourel&amp;hdr-1-name=subject&amp;hdr-1-query=&amp;index-grp=Public__FULL&amp;index-type=t&amp;type-index=www-forms-editor</font></a>
  <br>
  <br><font size=2 face="sans-serif">Cheers,</font>
  <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br>
  STSM: Lotus Forms Architect and Researcher<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>
  <br>
  </font>
  <br>
  <br>
  <br>
  <table width=100%>
  <tr valign=top>
  <td width=40%><font size=1 face="sans-serif"><b>&quot;Richard Ishida&quot;
  &lt;ishida@w3.org&gt;</b> </font>
  <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font>
  <p><font size=1 face="sans-serif">07/30/2007 03:38 AM</font>
  <td width=59%>
  <table width=100%>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">To</font></div>
  <td><font size=1 face="sans-serif">&quot;'John Boyer'&quot; &lt;xforms-issues@mn.aptest.com&gt;,
  &lt;fsasaki@w3.org&gt;</font>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">cc</font></div>
  <td><font size=1 face="sans-serif">&lt;www-forms-editor@w3.org&gt;, &lt;www-international@w3.org&gt;</font>
  <tr valign=top>
  <td>
  <div align=right><font size=1 face="sans-serif">Subject</font></div>
  <td><font size=1 face="sans-serif">RE: [XForms 1.1] i18n comment: Various
  comments on XForms 1.1 (PR#15)</font></table>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br>
  <br>
  <br><tt><font size=2><br>
  John,<br>
  <br>
  Could you provide some links please? &nbsp;A quick look didn't reveal the<br>
  location of the relevant information, and may have missed some important<br>
  bits.<br>
  <br>
  Thanks,<br>
  RI<br>
  <br>
  ============<br>
  Richard Ishida<br>
  Internationalization Lead<br>
  W3C (World Wide Web Consortium)<br>
   <br>
  </font></tt><a href=http://www.w3.org/People/Ishida/><tt><font size=2>http://www.w3.org/People/Ishida/</font></tt></a><tt><font size=2><br>
  </font></tt><a href=http://www.w3.org/International/><tt><font size=2>http://www.w3.org/International/</font></tt></a><tt><font size=2><br>
  </font></tt><a href=http://people.w3.org/rishida/blog/><tt><font size=2>http://people.w3.org/rishida/blog/</font></tt></a><tt><font size=2><br>
  </font></tt><a href=http://www.flickr.com/photos/ishida/><tt><font size=2>http://www.flickr.com/photos/ishida/</font></tt></a><tt><font size=2><br>
   <br>
   <br>
  <br>
  &gt; -----Original Message-----<br>
  &gt; From: www-international-request@w3.org <br>
  &gt; [</font></tt><a href="mailto:www-international-request@w3.org"><tt><font size=2>mailto:www-international-request@w3.org</font></tt></a><tt><font size=2>]
  On Behalf Of John Boyer<br>
  &gt; Sent: 26 July 2007 19:40<br>
  &gt; To: fsasaki@w3.org<br>
  &gt; Cc: www-forms-editor@w3.org; www-international@w3.org<br>
  &gt; Subject: Re: [XForms 1.1] i18n comment: Various comments on <br>
  &gt; XForms 1.1 (PR#15)<br>
  &gt; <br>
  &gt; <br>
  &gt; Answers for all last call comments attributed to Yves <br>
  &gt; Savourel are now available in the www-forms-editor list <br>
  &gt; archive and the results of spec changes now appear in the <br>
  &gt; editor's draft available from the Forms WG website.<br>
  &gt; <br>
  &gt; Best regards,<br>
  &gt; John Boyer<br>
  &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; Comment from the i18n review of:<br>
  &gt; &gt; </font></tt><a href="http://www.w3.org/TR/2007/WD-xforms11-20070222/"><tt><font size=2>http://www.w3.org/TR/2007/WD-xforms11-20070222/</font></tt></a><tt><font size=2><br>
  &gt; &gt; <br>
  &gt; &gt; Comment 10<br>
  &gt; &gt; At </font></tt><a href="http://www.w3.org/International/reviews/0704-xforms11/"><tt><font size=2>http://www.w3.org/International/reviews/0704-xforms11/</font></tt></a><tt><font size=2><br>
  &gt; &gt; Editorial/substantive: S<br>
  &gt; &gt; Location in reviewed document:<br>
  &gt; &gt; Various<br>
  &gt; &gt; Various comments on XForms 1.1<br>
  &gt; &gt; <br>
  &gt; &gt; Comment:<br>
  &gt; &gt; The Working Group endorses the coment sent by Yves Savourel <br>
  &gt; &gt; <br>
  &gt; </font></tt><a href="http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html"><tt><font size=2>http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html</font></tt></a><tt><font size=2><br>
  &gt; &gt; <br>
  &gt; [</font></tt><a href="http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.htm"><tt><font size=2>http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.htm</font></tt></a><tt><font size=2><br>
  &gt; &gt; l] , especially comment 1 (\&quot;Is the WG planning to provide
  <br>
  &gt; an ITS Rule <br>
  &gt; &gt; file along with the specification (e.g. as a non-normative <br>
  &gt; &gt; appendix)?\&quot;) Pleasekeep us in the loop during your <br>
  &gt; discussion of the <br>
  &gt; &gt; comments.<br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  &gt; <br>
  <br>
  <br>
  </font></tt>
  <br>
  --=_alternative 0071744D88257329_=--
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Answers for all last call comments attributed to Yves Savourel are now available
  in the www-forms-editor list archive and the results of spec changes now appear
  in the editor's draft available from the Forms WG website.
  
  Best regards,
  John Boyer
  
  > 
  > Comment from the i18n review of:
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > 
  > Comment 10
  > At http://www.w3.org/International/reviews/0704-xforms11/
  > Editorial/substantive: S
  > Location in reviewed document:
  > Various
  > Various comments on XForms 1.1
  > 
  > Comment:
  > The Working Group endorses the coment sent by Yves Savourel
  > http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html  
  > [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html]
  > , especially comment 1 (\"Is the WG planning to provide an ITS Rule file  
  > along with the specification (e.g. as a non-normative appendix)?\")  
  > Pleasekeep us in the loop during your discussion of the comments.
  > 
  > 
  > 

8.10 Upcoming RFC for Human Readable Resource Identifiers

PROBLEM ID: 38

STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  See this post from Norm Walsh:
  
      http://norman.walsh.name/2007/04/30/hrri
  
  This is something to keep in mind for future editions of the XForms spec
     once the RFC is out of draft status.
  
  Currently, XForms refers to the XLink specification for xforms:load, but
  it seems not for xforms:submission/(@action|@resource) or in other
  places. This does not make it very clear whether this section of XLink
  must be followed:
  
      http://www.w3.org/TR/xlink/#link-locators
  
  Further, even that section of XLink is obscure to me. So I think that
  once HHRIs are specified in that RFC, XForms should simply refer to that
  RFC to specify how any URI specified by a form author should be handled.
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Erik,
  
  we decided to defer this to future XForms, which may consider supporting HRRIs
  after IRI support is added.
  
  Regards,
  Ulrich Nicolas Lissé
  
  For the Forms WG
  
  > All,
  > 
  > See this post from Norm Walsh:
  > 
  >     http://norman.walsh.name/2007/04/30/hrri
  > 
  > This is something to keep in mind for future editions of the XForms spec
  >    once the RFC is out of draft status.
  > 
  > Currently, XForms refers to the XLink specification for xforms:load, but
  > it seems not for xforms:submission/(@action|@resource) or in other
  > places. This does not make it very clear whether this section of XLink
  > must be followed:
  > 
  >     http://www.w3.org/TR/xlink/#link-locators
  > 
  > Further, even that section of XLink is obscure to me. So I think that
  > once HHRIs are specified in that RFC, XForms should simply refer to that
  > RFC to specify how any URI specified by a form author should be handled.
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

8.11 Section 2

PROBLEM ID: 113

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  
  2) Section 2 mentions 'HTML forms' and 'HTML Forms'.  The capitalization
  probably needs to be consistent throughout the document.
  3) Section 2.1, "It is clear that we are collecting a value tht represents
  whether cash or credit card is being used..."  Probably need to say
  '...cash or a credit card...' just to be more grammatically correct.
  4) Section 2.3, "...because the evaluation context nodes for computed
  expressions are determined by the bind ref binding expression..."  ref
  should be nodeset here, since @ref isn't valid on a xf:bind.
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Thanks for these, Aaron.
  The spec is changed, but I did not diff-mark them.
  
  Best regards,
  John Boyer
  
  > 
  > 2) Section 2 mentions 'HTML forms' and 'HTML Forms'.  The capitalization
  > probably needs to be consistent throughout the document.
  > 3) Section 2.1, "It is clear that we are collecting a value tht represents
  > whether cash or credit card is being used..."  Probably need to say
  > '...cash or a credit card...' just to be more grammatically correct.
  > 4) Section 2.3, "...because the evaluation context nodes for computed
  > expressions are determined by the bind ref binding expression..."  ref
  > should be nodeset here, since @ref isn't valid on a xf:bind.
  > 
  > 

8.12 XForms 1.1 comments: miscellaneous typos

PROBLEM ID: 35

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Gary F Stevens" <gfsteven@us.ibm.com>
  
  
  
  
  
  This is a list of typos and other small errors I have come across in the
  XForms 1.1 Working Draft:
  
  
  3.3.1, version attribute, last sentence before the Note:  The word
  "version" is misspelled "versoin."
  
  3.3.2, resource attribute, first paragraph, last sentence: The sentence "If
  the host language may treat failure to traverse the link as an exception
  (4.5.2 The xforms-link-exception Event)" needs to be reworded.
  
  4.6.1, first and second bullets: The use of quotation marks is different
  between the two bullets.  The first one says 'the "incremental="true"
  setting' while the second one says 'the "incremental=true" setting.'
  
  7.6, last sentence: There is a dash missing between "binding" and
  "exception".
  
  9.3.1, number attribute, first paragraph, second sentence: The letter "i"
  in the word "if" at the start of the sentence needs to be capitalized.
  
  10.10.2, second paragraph, first sentence: The word "to" is misspelled "ot"
  and the word "the" is misspelled "th."
  
  11.2, first paragraph, second sentence: There is a closing parenthesis
  without an opening parenthesis.
  11.2, second bullet, second sentence: The letter "i" in the word "if" at
  the start of the sentence needs to be capitalized.
  
  11.7.2, first paragraph, first sentence: The sentence is missing the word
  "have"; it currently reads "The submission element can optionally a child
  element named verb,..."
  
  Gary F Stevens
  gfsteven@us.ibm.com
  Software Group - Emerging Standards
  IBM/US/Raleigh-RTP
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Gary,
  
  You are right. We will update the spec accordingly. 
  
  Many thanks.
  
  Nick Van den Bleeken
  For the Forms WG
  > 
  > 
  > 
  > 
  > This is a list of typos and other small errors I have come across in the
  > XForms 1.1 Working Draft:
  > 
  > 
  > 3.3.1, version attribute, last sentence before the Note:  The word
  > "version" is misspelled "versoin."
  > 
  > 3.3.2, resource attribute, first paragraph, last sentence: The sentence "If
  > the host language may treat failure to traverse the link as an exception
  > (4.5.2 The xforms-link-exception Event)" needs to be reworded.
  > 
  > 4.6.1, first and second bullets: The use of quotation marks is different
  > between the two bullets.  The first one says 'the "incremental="true"
  > setting' while the second one says 'the "incremental=true" setting.'
  > 
  > 7.6, last sentence: There is a dash missing between "binding" and
  > "exception".
  > 
  > 9.3.1, number attribute, first paragraph, second sentence: The letter "i"
  > in the word "if" at the start of the sentence needs to be capitalized.
  > 
  > 10.10.2, second paragraph, first sentence: The word "to" is misspelled "ot"
  > and the word "the" is misspelled "th."
  > 
  > 11.2, first paragraph, second sentence: There is a closing parenthesis
  > without an opening parenthesis.
  > 11.2, second bullet, second sentence: The letter "i" in the word "if" at
  > the start of the sentence needs to be capitalized.
  > 
  > 11.7.2, first paragraph, first sentence: The sentence is missing the word
  > "have"; it currently reads "The submission element can optionally a child
  > element named verb,..."
  > 
  > Gary F Stevens
  > gfsteven@us.ibm.com
  > Software Group - Emerging Standards
  > IBM/US/Raleigh-RTP
  > 
  > 

8.13 XForms 1.1 WD last call comments from CDFCDF01 - Abstract text moved to Introduction WG

PROBLEM ID: 124

STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: Agree

NOTES:

  The abstract of a document is supposed to be a miniature introduction to the
  document's content that helps a person decide whether or not they want to read
  the rest of the document.  The XForms 1.0 abstract was inadequate to this
  purpose.
  
  It is clear that the document is a specification for XForms, but the abstract
  cannot end there.  It must explain, basically, what XForms is.  The abstract
  then explains the relationship between XForms 1.1 and 1.0, which is also
  necessary.
  
  For an example of a similar abstract, please see XPath 2.0.

ORIGINAL MESSAGE:

  From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com>
  
  Move the current abstract text to Section 2 Introduction to XForms, and add
  appropriate abstract text stating what the document is in the abstract
  section.
  Rationale: http://www.w3.org/2001/06/manual/#Abstract, the current abstract
  text is really an introduction to XForms.
  

FOLLOWUP 1:

  From: member-cdf-request@w3.org
  
  *** NOTE: ***
  
      Your message was sent from an address which is not on the list
      of people who are authorized to post to this mailing list.
      Therefore, your message has been forwarded to the list maintainer
      for manual processing.
  
      If you do not see your message appear on the list or in the
      mailing list archives within a few business days, you may wish
      to contact the mailing list maintainer to investigate the delay.
  
      -- W3C Postmaster
         http://www.w3.org/Mail/
  
  your message follows:
  ----------------------------------------------------------------------------
  
  
  Dear CDF WG,
  
  The abstract of a document is supposed to be a miniature introduction to the
  document's content that helps a person decide whether or not they want to read
  the rest of the document.  The XForms 1.0 abstract was inadequate to this
  purpose.
  
  It is clear that the document is a specification for XForms, but the abstract
  cannot end there.  It must explain, basically, what XForms is.  The abstract
  then explains the relationship between XForms 1.1 and 1.0, which is also
  necessary.
  
  For an example of a similar abstract, please see XPath 2.0.
  
  Regards,
  
  Nick Van den Bleeken
  
  > Move the current abstract text to Section 2 Introduction to XForms, and add
  > appropriate abstract text stating what the document is in the abstract
  > section.
  > Rationale: http://www.w3.org/2001/06/manual/#Abstract, the current abstract
  > text is really an introduction to XForms.
  > 
  > 
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear CDF WG,
  
  The abstract of a document is supposed to be a miniature introduction to the
  document's content that helps a person decide whether or not they want to read
  the rest of the document.  The XForms 1.0 abstract was inadequate to this
  purpose.
  
  It is clear that the document is a specification for XForms, but the abstract
  cannot end there.  It must explain, basically, what XForms is.  The abstract
  then explains the relationship between XForms 1.1 and 1.0, which is also
  necessary.
  
  For an example of a similar abstract, please see XPath 2.0.
  
  Regards,
  
  Nick Van den Bleeken
  
  > Move the current abstract text to Section 2 Introduction to XForms, and add
  > appropriate abstract text stating what the document is in the abstract
  > section.
  > Rationale: http://www.w3.org/2001/06/manual/#Abstract, the current abstract
  > text is really an introduction to XForms.
  > 
  > 

9. Model

9.1 [LC: Editorial]

PROBLEM ID: 94

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  3.3.4 The bind Element

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#structure-bind-element
  
  Please add a link to Section 6 for details of MIPS
  
  Steven
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  Done.  Please see the editor's draft available from the Forms WG website.
  
  Thanks,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#structure-bind-element
  > 
  > Please add a link to Section 6 for details of MIPS
  > 
  > Steven
  > 
  > 

9.2 More on datatype validation: what's a possible algorithm?

PROBLEM ID: 86

STATE: Approved and Implemented
EDIT: None
RESOLUTION: Accept
USER POSITION: Agree

NOTES:

  There is an 'accept' with no edits here because we basically agreed not to do
  some work that had not already been done.

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  Let's continue with some schema questions. As discussed in this
  thread:
  
      http://lists.w3.org/Archives/Public/public-forms/2007May/0074.html
  
  there is a pending action item to amend the spec so that "revalidate
  only perform validation of datatypes, not structural validation,
  *except* during submission".
  
  Now I am just wondering how an implementation can do this. If you
  assign datatypes with xforms:bind or xsi:type, then it is quite
  easy.
  
  Now if you don't have those, but the types come directly from the
  schema, what do you do?
  
  Let's say I define a simple type like this in a schema:
  
  <xs:simpleType name="state">
            <xs:restriction base="xs:string">
                <xs:enumeration value="AL"/>
                  ...
  
  I just wouldn't know what nodes in the document have this type. Of
  course, I know it if I write in my schema:
  
  <xs:element name="state" type="dmv:state"/>
  
  But this may or may not be a top-level definition in my schema. If it
  is, then I can assume that any element called "state" will have type
  state. So I validate the content of the element and there is no
  problem.
  
  What if this is not a top-level definition? Should an implementation
  do the following:
  
  1. Do a full validation.
  2. While doing so, annotate nodes with appropriate type information.
  3. Use that type information during revalidate.
  
  But then, what happens if you do any of the following:
  
  * xforms:insert
  * submission with instance replacement
  
  The newly created nodes won't have any type information associated
  with them, unless you do a full revalidation. So should we expect that
  full validation occurs "when needed" to determine node types?
  
  Or am I missing something?
  
  Feedback would be appreciated on this.
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Erik,
  
  At the last face-to-face meeting, the working group resolved to nullify the
  offending action item you mentioned below, so the spec change that would result
  in the problems you identify below will not be made.
  
  We trust that this satisfies your last call comment.
  
  Thank you,
  John Boyer
  
  > 
  > All,
  > 
  > Let's continue with some schema questions. As discussed in this
  > thread:
  > 
  >     http://lists.w3.org/Archives/Public/public-forms/2007May/0074.html
  > 
  > there is a pending action item to amend the spec so that "revalidate
  > only perform validation of datatypes, not structural validation,
  > *except* during submission".
  > 
  > Now I am just wondering how an implementation can do this. If you
  > assign datatypes with xforms:bind or xsi:type, then it is quite
  > easy.
  > 
  > Now if you don't have those, but the types come directly from the
  > schema, what do you do?
  > 
  > Let's say I define a simple type like this in a schema:
  > 
  > <xs:simpleType name="state">
  >           <xs:restriction base="xs:string">
  >               <xs:enumeration value="AL"/>
  >                 ...
  > 
  > I just wouldn't know what nodes in the document have this type. Of
  > course, I know it if I write in my schema:
  > 
  > <xs:element name="state" type="dmv:state"/>
  > 
  > But this may or may not be a top-level definition in my schema. If it
  > is, then I can assume that any element called "state" will have type
  > state. So I validate the content of the element and there is no
  > problem.
  > 
  > What if this is not a top-level definition? Should an implementation
  > do the following:
  > 
  > 1. Do a full validation.
  > 2. While doing so, annotate nodes with appropriate type information.
  > 3. Use that type information during revalidate.
  > 
  > But then, what happens if you do any of the following:
  > 
  > * xforms:insert
  > * submission with instance replacement
  > 
  > The newly created nodes won't have any type information associated
  > with them, unless you do a full revalidation. So should we expect that
  > full validation occurs "when needed" to determine node types?
  > 
  > Or am I missing something?
  > 
  > Feedback would be appreciated on this.
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

9.3 [XForms 1.1] i18n comment: Responsibility for useability of IRIs unclear

PROBLEM ID: 13

STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree

NOTES:

  Felix Sasaki accepted this resolution because we had already indicated clearly
  that we fully support xsd:anyURI, which implies broad support for IRIs anyway,
  despite  some edge case exceptionalities.

ORIGINAL MESSAGE:

  From: fsasaki@w3.org
  
  
  Comment from the i18n review of:
  http://www.w3.org/TR/2007/WD-xforms11-20070222/
  
  Comment 4
  At http://www.w3.org/International/reviews/0704-xforms11/
  Editorial/substantive: S
  Location in reviewed document:
  3.2.2
  Responsibility for useability of IRIs unclear
  
  Comment:
  
    The host language may permit a Linking Attributes Collection to be  
  applied to XForms elements as an alternate means of obtaining content  
  related to the element. An example is the src attribute from [XHTML 1.0].  
  The schedule by which link traversal occurs is defined by the host  
  language. If the link traversal fails, the host language may dispatch  
  xforms-link-exception or xforms-link-error to the model associated with  
  the in-scope evaluation context node of the element that bears the Linking  
  Attributes Collection for the failed link.
  
  Does this mean that the host language is responsible whether XForms allows  
  for using
  IRIs [http://www.ietf.org/rfc/rfc3987.txt]
    or not? Please answer this question in the specification and provide a  
  reference (normative or informative, depending on the answer) to the IRI  
  specification.
  
  
  
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Felix,
  
  due to other last call comments, src was moved from host language control to
  XForms, where it is governed by rules of xsd:anyURI from schema 1.0. Since
  Schema 1.0 doesn't support IRIs clearly and completely we don't reference the
  IRI RFC.
  
  Regards,
  Ulrich Nicolas Lissé
  
  For the Forms WG
  
  > Comment from the i18n review of:
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > 
  > Comment 4
  > At http://www.w3.org/International/reviews/0704-xforms11/
  > Editorial/substantive: S
  > Location in reviewed document:
  > 3.2.2
  > Responsibility for useability of IRIs unclear
  > 
  > Comment:
  > 
  >   The host language may permit a Linking Attributes Collection to be  
  > applied to XForms elements as an alternate means of obtaining content  
  > related to the element. An example is the src attribute from [XHTML 1.0].  
  > The schedule by which link traversal occurs is defined by the host  
  > language. If the link traversal fails, the host language may dispatch  
  > xforms-link-exception or xforms-link-error to the model associated with  
  > the in-scope evaluation context node of the element that bears the Linking  
  > Attributes Collection for the failed link.
  > 
  > Does this mean that the host language is responsible whether XForms allows  
  > for using
  > IRIs [http://www.ietf.org/rfc/rfc3987.txt]
  >   or not? Please answer this question in the specification and provide a  
  > reference (normative or informative, depending on the answer) to the IRI  
  > specification.
  > 
  > 
  > 
  > 
  > 

9.4 [LC] 3.3.2 The instance Element

PROBLEM ID: 93

STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#structure-model-instance
  
  (Sorry that these are so late, but I was rereading the spec in the plane
  this week, and saw these things, and thought better to comment than not)
  
  This section says "If both the resource attribute and inline content are
  provided, the inline content takes precedence as described at 4.2.1 The
  xforms-model-construct Event. "
  
  Are we sure that this is the best approach? I seem to remember that the
  discussion was about freeing two birds with one key:
  
  	If the resource URL fails, then use the inline content.
  
  The advantage being, the inline instance can provide a template, and the
  resource can supply the 'saved' version. So the first time you run an
  application, you get the default content (such as an empty to-do list),
  and when you save it to some resource, future times you start up you get
  the saved version.
  
  Steven
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  Actually, this is not how the resource attribute works and was not part of the
  discussion about adding the resource attribute.  The resource attribute is not
  even resolved unless there is no inline content.  The intent was to allow
  something *similar* to what you have described, though.
  
  When a form is first served out to the user, their may be no prepopulation data
  for the instance, in which case it is left blank and thus the resource attribute
  is resolved and the empty template instance data is used.  The user may then
  interact with the instance data and "save" the instance data. This may occur by
  submitting the data to a server-side database or, in a document-centric XForms
  system, it may occur by placing the serialization of the instance data into the
  xforms:instance before serializing the document containing the XForm to disk. 
  Either way, when the form is next provided to the user, the saved instance data
  either is or can be placed into the xforms:instance element as prepopulation
  data that overrides the resource attribute.
  
  In conclusion, the resolution of the resource attribute only after checking for
  inline content is by design, so I hope that this response satisfies your concern
  about the behavior of the resource attribute.
  
  Thanks,
  John Boyer
  

9.5 LC: Problems with Binding Expressions changing evaluation context of other attributes

PROBLEM ID: 28

STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: "John Boyer" <boyerj@ca.ibm.com>
  
  Once a binding expression on an element is evaluated, XForms uses the
  identified node as the context node for other attributes on the same
  element.
  
  One example where that creates a limitation is given in the following last
  call comment:
  http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0042.html
  
  But other cases exist.  For example, if an instance has three instance
  nodes as follows:
  
  <data>
     <a>2</a>
     <b>2</b>
     <c>4</c>
  </data>
  
  then one must write the following to put the result of a+b into c:
  
  <bind nodeset="c" calculate="../a + ../b"/>
  
  The excessive dots are a nuisance, and when the novice writes what is
  reasonable to expect-- calculate="a+b"-- the result is NaN.  This is
  because the calculate is interpreted relative to the node c, and the node
  c has no child elements named a and b.  The dots are needed to traverse up
  to the parent of c so that its siblings may be obtained.
  
  The problem becomes more acute in larger formulae, which occur often in
  constraints.
  
  It should be noted that fixing this problem might mean that the above bind
  would no longer be equal to the following nested bind (because the outer
  bind sets the evaluation context for the inner bind):
  
  <bind nodeset="c">
       <bind calculate="../a + ../b"/>
  </bind>
  
  It is a decision point as to whether preserving that equivalence between
  the nested and non-nested bind is important.  If not, then the nested bind
  would give another way to get the old 1.0 behavior back for those who want
  it.  If so, then that might simply affect how the problem is solved.
  
  Needless to say, it would be too problematic for the existing XForms
  community to do away with the current method of determining the evaluation
  context for attributes like @calculate on bind or @value on setvalue.  So
  we would need some kind of attribute for turning on a different method.
  This attribute could *default* to the new method when the XForms model
  @version attribute is set to 1.1.
  
  Perhaps something like <model unifiedcontext="false" version="1.1" ...>
  would suffice to keep the old context evaluation in 1.0, and one could
  optionally write unifiedcontext="true" to make the change to having all
  attributes of an element use the same eval context.  And,
  unifiedcontext="true" could be the default for version="1.1" XForms.
  
  I don't have a good solution yet for how this could be done if the nested
  bind and non-nested bind cases above must remain equivalent, but last call
  rules say my proposal does not have to be complete, and in this case, I
  call out this equivalence as a decision point, so we don't have to solve
  it if the answer is no.
  
  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
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  John,
  
  we agree that we need a simpler version, but that it is in scope of XForms 1.2,
  so this issue is deferred.
  
  Regards,
  Ulrich Nicolas Lissé
  
  For the Forms WG
  
  > Once a binding expression on an element is evaluated, XForms uses the
  > identified node as the context node for other attributes on the same
  > element.
  > 
  > One example where that creates a limitation is given in the following last
  > call comment:
  > http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0042.html
  > 
  > But other cases exist.  For example, if an instance has three instance
  > nodes as follows:
  > 
  > <data>
  >    <a>2</a>
  >    <b>2</b>
  >    <c>4</c>
  > </data>
  > 
  > then one must write the following to put the result of a+b into c:
  > 
  > <bind nodeset="c" calculate="../a + ../b"/>
  > 
  > The excessive dots are a nuisance, and when the novice writes what is
  > reasonable to expect-- calculate="a+b"-- the result is NaN.  This is
  > because the calculate is interpreted relative to the node c, and the node
  > c has no child elements named a and b.  The dots are needed to traverse up
  > to the parent of c so that its siblings may be obtained.
  > 
  > The problem becomes more acute in larger formulae, which occur often in
  > constraints.
  > 
  > It should be noted that fixing this problem might mean that the above bind
  > would no longer be equal to the following nested bind (because the outer
  > bind sets the evaluation context for the inner bind):
  > 
  > <bind nodeset="c">
  >      <bind calculate="../a + ../b"/>
  > </bind>
  > 
  > It is a decision point as to whether preserving that equivalence between
  > the nested and non-nested bind is important.  If not, then the nested bind
  > would give another way to get the old 1.0 behavior back for those who want
  > it.  If so, then that might simply affect how the problem is solved.
  > 
  > Needless to say, it would be too problematic for the existing XForms
  > community to do away with the current method of determining the evaluation
  > context for attributes like @calculate on bind or @value on setvalue.  So
  > we would need some kind of attribute for turning on a different method.
  > This attribute could *default* to the new method when the XForms model
  > @version attribute is set to 1.1.
  > 
  > Perhaps something like <model unifiedcontext="false" version="1.1" ...>
  > would suffice to keep the old context evaluation in 1.0, and one could
  > optionally write unifiedcontext="true" to make the change to having all
  > attributes of an element use the same eval context.  And,
  > unifiedcontext="true" could be the default for version="1.1" XForms.
  > 
  > I don't have a good solution yet for how this could be done if the nested
  > bind and non-nested bind cases above must remain equivalent, but last call
  > rules say my proposal does not have to be complete, and in this case, I
  > call out this equivalence as a decision point, so we don't have to solve
  > it if the answer is no.
  > 
  > 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
  > 
  > 

9.6 Section 3

PROBLEM ID: 114

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response

NOTES:

  Editorial fixes, most of which were accepted.  Non-accepted are not technical
  (e.g. the version of XHTML we cite).

ORIGINAL MESSAGE:

  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  5) Section 3, Document structure - mentions XHTML 1.0.  Shouldn't that be
  XHTML 2.0?
  6) Section 3.2.3 and 3.2.4 - the string 'IDREF' is used in different fonts
  at different times but it seems to me it is used the same way in both
  cases.  For example, the phrase "or a bind IDREF value that refers to an ID
  not on a bind element" is used in both sections and in one place 'id' is
  used, in another 'ID' is used.  And in one place IDREF is in a fixed font
  and in the other it looks like the default font.  It gets confusing.
  7) Section 3.3.1 "has no predefined behavior event-based behavior."
  Doesn't make sense having 'behavior' here twice.
  8) Section 3.3.1 - "If any non-default model has a versoin..." version is
  misspelled.
  9) Section 3.3.2 - resource attribute - you are introducing a new attribute
  to the instance element and don't have it in the 1.1 schema?  You could
  also break the xforms out there that currently use @src on the instance
  element.  -> Section 3.2.2 says that the host language can allow @src on
  xforms elements, for example.  So what should happen if @src and @resource
  are on the element?  Who wins?  The text in 3.3.2 says that the host
  language linking attribute 'MAY' win.  That doesn't help anyone.  How is a
  form author supposed to code to that?  Seems to me like this change needs
  more thought.
  10) Section 3.3.2 - incomplete sentence -> "If the host language may treat
  failure to traverse the link as an exception" is an incomplete sentence.
  11) Section 3.3.2 - "All data relevant to the XPath data model must be
  preserved during processing and submission, including processing
  instructions, comment nodes and all whitespace".  What about if @indent is
  specified on xf:submission?  Whitespace won't be preserved during
  submission then.
  12) Section 3.3.4 - "Element bind selects a node-set selected from the
  instance data" seems like poor wording to me.  Why not just say, "Element
  bind selects a node-set from the instance data"?
  13) Section 3.3.4 - two periods terminating the sentence right before
  section 3.4.
  14) Section 3.5 - "Another common approach is to allow unregulated content
  in a few selected places."  Should probably be "...in a few select places."
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  Here are responses to several issues you raised in a last call comment on April
  30th.  Please let us know if you have any further concerns.
  
  Thanks,
  John Boyer
  
  5) Section 3, Document structure - mentions XHTML 1.0.  Shouldn't that be
  XHTML 2.0?
  
  It refers to a 'future version' of XHTML, then cites XHTML 1.0, which
  very well could be XHTML 2 but also pre-XHTML2 modularization profiles.
  We cite 1.0 because it is a recommendation.
  
  6) Section 3.2.3 and 3.2.4 - the string 'IDREF' is used in different fonts
  at different times but it seems to me it is used the same way in both
  cases.  For example, the phrase "or a bind IDREF value that refers to an ID
  not on a bind element" is used in both sections and in one place 'id' is
  used, in another 'ID' is used.  And in one place IDREF is in a fixed font
  and in the other it looks like the default font.  It gets confusing.
  
  The last sentence of 3.2.4 was the parallel of the second to last in 3.2.3.
  In 3.2.3, the correct fixed font and capitalization was used, but not in 3.2.4.
  
  Done. Not diff-marked.
  
  7) Section 3.3.1 "has no predefined behavior event-based behavior."
  Doesn't make sense having 'behavior' here twice.
  
  Removed the entire offending phrase as the independent clause of the
  sentence is sufficient.  Diff-marked.
  
  8) Section 3.3.1 - "If any non-default model has a versoin..." version is
  misspelled.
  
  Fixed as part of a larger fix. Diff-marked.
  
  9) Section 3.3.2 - resource attribute - you are introducing a new attribute
  to the instance element and don't have it in the 1.1 schema?  You could
  also break the xforms out there that currently use @src on the instance
  element.  -> Section 3.2.2 says that the host language can allow @src on
  xforms elements, for example.  So what should happen if @src and @resource
  are on the element?  Who wins?  The text in 3.3.2 says that the host
  language linking attribute 'MAY' win.  That doesn't help anyone.  How is a
  form author supposed to code to that?  Seems to me like this change needs
  more thought.
  
  XForms now adds the src attribute to the instance element, rather than 
  depending on this attribute from the host language.
  A note was added to 3.2.2 (linking attributes), the attribute was added to 
  3.3.2 (instance element), and the description of model construction in 
  4.2.1 is also modified.  Diff-marked.
  
  
  10) Section 3.3.2 - incomplete sentence -> "If the host language may treat
  failure to traverse the link as an exception" is an incomplete sentence.
  
  The problem is fixed via the substantive change to add src to instance.
  Removal of the word 'If' is not directly diff-marked.
  
  11) Section 3.3.2 - "All data relevant to the XPath data model must be
  preserved during processing and submission, including processing
  instructions, comment nodes and all whitespace".  What about if @indent is
  specified on xf:submission?  Whitespace won't be preserved during
  submission then.
  
  Changed to "during process and as input to submission serialization"
  Diff-marked.
  
  12) Section 3.3.4 - "Element bind selects a node-set selected from the
  instance data" seems like poor wording to me.  Why not just say, "Element
  bind selects a node-set from the instance data"?
  
  Done. Not diff-marked.
  
  13) Section 3.3.4 - two periods terminating the sentence right before
  section 3.4.
  
  Done. Not diff-marked.
  
  14) Section 3.5 - "Another common approach is to allow unregulated content
  in a few selected places."  Should probably be "...in a few select places."
  
  Done. Not diff-marked.

9.7 1) MustUnderstand

PROBLEM ID: 112

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  Another last call comment also requested removal of this optional module because
  it is not widely implemented as an optional module; the reason, in turn, is that
  it appears to be a CDF problem, not something that can be solved by XForms
  alone.

ORIGINAL MESSAGE:

  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  1) I thought that the 1.1 spec would drop/deprecate MustUnderstand until it
  was better defined.  But it is still there.
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thanks for the comment. This hsa now been fixed.
  
  Best wishes,
  
  Steven Pemberton
  For the FOrms WG
  
  > 1) I thought that the 1.1 spec would drop/deprecate MustUnderstand until it
  > was better defined.  But it is still there.

9.8 [LC] 3.2.1 Common Attributes

PROBLEM ID: 56

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#structure-attrs-common
  
  Please allow both id= and xml:id=
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The working group agreed that it should be clarified that xml:id can also be
  used, not just the id attribute that is listed in the common attributes.   At
  the most recent face to face meeting, a Note was added to point this out. 
  Please see the revised text in the editor's draft available from the working
  group website and let us know if you have any further concerns about this
  issue.
  
  Thanks,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#structure-attrs-common
  > 
  > Please allow both id= and xml:id=
  > 
  > 
  > 

9.9 [XForms 1.1] i18n comment: IRIs for external schema locations possible?

PROBLEM ID: 8

STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree

ORIGINAL MESSAGE:

  From: fsasaki@w3.org
  
  
  Comment from the i18n review of:
  http://www.w3.org/TR/2007/WD-xforms11-20070222/
  
  Comment 5
  At http://www.w3.org/International/reviews/0704-xforms11/
  Editorial/substantive: S
  Location in reviewed document:
  4.2.1
  IRIs for external schema locations possible?
  
  Comment:
  As part of the xforms-model-construct Event, you describe that all XML  
  Schemas are loaded. Is it possible to use
  IRIs [http://www.ietf.org/rfc/rfc3987.txt]
    for identifying external schemas? See also comment 4 of the i18n core  
  comments.
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  Of the four points you make below, three are editorial and have been corrected.
  
  In addition, the use of the "barename" terminology was incorrect and has also
  been fixed.  It was alluding to a barename XPointer, but the terminology has now
  been corrected to indicate a fragment identifier URI Reference (including the
  leading # mark), which is the proper term from RFC 2396.  Please see the
  diff-marked text in the editor's draft available from the Forms WG website and
  let us know if you have any more concerns about this issue.
  
  Thanks,
  John Boyer 
  
  > 
  > http://www.w3.org/TR/xforms11/#structure-model-instance
  > 
  > Has the sentence "If the host language may treat failure to traverse
  > the link as an exception (4.5.2 The xforms-link-exception Event)."
  > 
  > It also contains the sentence ending:
  > 
  > "with a resource-uri indicating either the URI for an external
  > instance, a barename URI reference to an identified internal instance,
  > or empty string for an with an unidentified internal instance. .|"
  > which
  > - ends with two full-stops
  > - "empty string for an with an"
  > - I don't know what a barename URI reference is.
  > 
  > 

REPLY 2:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Felix,
  
  XForms 1.1 is based on XML Schema 1.0 second ed., which does not appear to
  support all IRIs in the xsd:anyURI type. Therefore we will defer the support of
  all IRIs to a future version of XForms, which may be based on a version of
  schema later than 1.0 that will support all IRIs.  
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > Comment from the i18n review of:
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > 
  > Comment 5
  > At http://www.w3.org/International/reviews/0704-xforms11/
  > Editorial/substantive: S
  > Location in reviewed document:
  > 4.2.1
  > IRIs for external schema locations possible?
  > 
  > Comment:
  > As part of the xforms-model-construct Event, you describe that all XML  
  > Schemas are loaded. Is it possible to use
  > IRIs [http://www.ietf.org/rfc/rfc3987.txt]
  >   for identifying external schemas? See also comment 4 of the i18n core  
  > comments.
  > 
  > 
  > 

REPLY 3:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  John,
  
  we agree that we need a simpler version, but that it is in scope of XForms 1.2,
  so this issue is deferred.
  
  Regards,
  Ulrich Nicolas Lissé
  
  For the Forms WG
  
  > Once a binding expression on an element is evaluated, XForms uses the
  > identified node as the context node for other attributes on the same
  > element.
  > 
  > One example where that creates a limitation is given in the following last
  > call comment:
  > http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0042.html
  > 
  > But other cases exist.  For example, if an instance has three instance
  > nodes as follows:
  > 
  > <data>
  >    <a>2</a>
  >    <b>2</b>
  >    <c>4</c>
  > </data>
  > 
  > then one must write the following to put the result of a+b into c:
  > 
  > <bind nodeset="c" calculate="../a + ../b"/>
  > 
  > The excessive dots are a nuisance, and when the novice writes what is
  > reasonable to expect-- calculate="a+b"-- the result is NaN.  This is
  > because the calculate is interpreted relative to the node c, and the node
  > c has no child elements named a and b.  The dots are needed to traverse up
  > to the parent of c so that its siblings may be obtained.
  > 
  > The problem becomes more acute in larger formulae, which occur often in
  > constraints.
  > 
  > It should be noted that fixing this problem might mean that the above bind
  > would no longer be equal to the following nested bind (because the outer
  > bind sets the evaluation context for the inner bind):
  > 
  > <bind nodeset="c">
  >      <bind calculate="../a + ../b"/>
  > </bind>
  > 
  > It is a decision point as to whether preserving that equivalence between
  > the nested and non-nested bind is important.  If not, then the nested bind
  > would give another way to get the old 1.0 behavior back for those who want
  > it.  If so, then that might simply affect how the problem is solved.
  > 
  > Needless to say, it would be too problematic for the existing XForms
  > community to do away with the current method of determining the evaluation
  > context for attributes like @calculate on bind or @value on setvalue.  So
  > we would need some kind of attribute for turning on a different method.
  > This attribute could *default* to the new method when the XForms model
  > @version attribute is set to 1.1.
  > 
  > Perhaps something like <model unifiedcontext="false" version="1.1" ...>
  > would suffice to keep the old context evaluation in 1.0, and one could
  > optionally write unifiedcontext="true" to make the change to having all
  > attributes of an element use the same eval context.  And,
  > unifiedcontext="true" could be the default for version="1.1" XForms.
  > 
  > I don't have a good solution yet for how this could be done if the nested
  > bind and non-nested bind cases above must remain equivalent, but last call
  > rules say my proposal does not have to be complete, and in this case, I
  > call out this equivalence as a decision point, so we don't have to solve
  > it if the answer is no.
  > 
  > 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
  > 
  > 

9.10 [LC] 3.3.2 The instance Element

PROBLEM ID: 58

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#structure-model-instance
  
  Has the sentence "If the host language may treat failure to traverse
  the link as an exception (4.5.2 The xforms-link-exception Event)."
  
  It also contains the sentence ending:
  
  "with a resource-uri indicating either the URI for an external
  instance, a barename URI reference to an identified internal instance,
  or empty string for an with an unidentified internal instance. .|"
  which
  - ends with two full-stops
  - "empty string for an with an"
  - I don't know what a barename URI reference is.
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  Of the four points you make below, three are editorial and have been corrected.
  
  In addition, the use of the "barename" terminology was incorrect and has also
  been fixed.  It was alluding to a barename XPointer, but the terminology has now
  been corrected to indicate a fragment identifier URI Reference (including the
  leading # mark), which is the proper term from RFC 2396.  Please see the
  diff-marked text in the editor's draft available from the Forms WG website and
  let us know if you have any more concerns about this issue.
  
  Thanks,
  John Boyer 
  
  > 
  > http://www.w3.org/TR/xforms11/#structure-model-instance
  > 
  > Has the sentence "If the host language may treat failure to traverse
  > the link as an exception (4.5.2 The xforms-link-exception Event)."
  > 
  > It also contains the sentence ending:
  > 
  > "with a resource-uri indicating either the URI for an external
  > instance, a barename URI reference to an identified internal instance,
  > or empty string for an with an unidentified internal instance. .|"
  > which
  > - ends with two full-stops
  > - "empty string for an with an"
  > - I don't know what a barename URI reference is.
  > 
  > 

9.11 [LC] 3.2.2 Linking Attributes

PROBLEM ID: 55

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: Agree

NOTES:

  This is only a modestly substantive change w.r.t. the last call document.
  XForms has always supported src, and we tried one way of expressing that more
  clearly in LC; we now express it much more clearly by adopting it into XForms
  from the host language.  This reflects how implementers are actually processing
  it, and it satifies this LC comment, and it helped to resolve the I18N group's
  issue with whether or not we support all of xsd:anyURI (which could not be
  stated definitively while src remained a host language construct).  So we do
  not expect any objection to this change.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#structure-attrs-common
  http://www.w3.org/TR/xforms11/#structure-attrs-link
  
  It really looks like @src has been removed, and replaced by
  @resource. I think this sends the wrong message, especially if the
  reasoning is that the host language should provide src, since @id was
  not included in XForms 1.0 for that reason, and now has been added to
  XForms 1.1. Please add @src back, lest implementors should leave it
  out, and old forms not work. (@resource will be dealt with in another
  issue).
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The working group agreed with you that it was better to specify src on instance
  as part of XForms rather than relying upon the host language to add it.  This
  was viewed as being consistent with our earlier addition of the id attribute to
  the common attributes (i.e. we agreed it was generally true that if an
  attribute
  is needed to produce some core required behavior, then the attribute should
  appear in the XForms schema).
  
  You can find the revised text with diff marks in the editor's draft available
  from the Forms WG website at
  http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-model-instance
  
  Please let us know if you have any concerns about this resolution.
  
  Thanks,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#structure-attrs-common
  > http://www.w3.org/TR/xforms11/#structure-attrs-link
  > 
  > It really looks like @src has been removed, and replaced by
  > @resource. I think this sends the wrong message, especially if the
  > reasoning is that the host language should provide src, since @id was
  > not included in XForms 1.0 for that reason, and now has been added to
  > XForms 1.1. Please add @src back, lest implementors should leave it
  > out, and old forms not work. (@resource will be dealt with in another
  > issue).
  > 
  > 

9.12 Question regarding TestCase 3.4.1.a and mustUnderstand

PROBLEM ID: 2

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  Group has agreed to remove mustunderstand.
  This was an optional module that was not widely implemented because it is a CDF
  problem, not something that can be solved in XForms.

ORIGINAL MESSAGE:

  From: "Steve K Speicher" <sspeiche@us.ibm.com>
  
  
  I have a question regarding the validity of the XForm's testsuite case
  3.4.1[1] with respect to mustUnderstand [2].
  
  I know that some of these issues have already been raised [3] but wanted
  to state that Mozilla XForms is currently not adding support for this [4]
  due to some of these issues.
  
  We are considering the test case 3.4.1 to be invalid until these issues
  are resolved.
  
  Here are some of the issues with mustUnderstand:
     - When does it get evaluated?  Must it be handled prior to xforms-ready
  or say if it's in a switch/case, only when the case is activated?
     - Can mustUnderstand be manipulated by script? If nodes are dynamically
  added to layout but conflicts with mustUnderstand, what error should
  occur?
  
  Perhaps a better fallback mechanism should be used.  Though I might
  propose completely removing mustUnderstand as I don't know of anyone who
  has implemented it.  Another thought is to seek feedback or give
  requirements to the CDF WG [5], as they are currently dealing with such
  issues around mixing namespace documents and content negotiation and
  fallback handling of unknown content.
  
  Regards,
  Steve Speicher
  
  [1]
  http://www.w3.org/MarkUp/Forms/Test/XForms1.0/Edition2/Chapt3/3.4/3.4.1/3.4.1.a.xhtml
  [2] http://www.w3.org/TR/xforms/slice3.html#module-mustUnderstand
  [3] http://lists.w3.org/Archives/Public/www-forms/2002Aug/0149
  [4] https://bugzilla.mozilla.org/show_bug.cgi?id=299255
  [5] http://www.w3.org/2004/CDF/
  
  

FOLLOWUP 1:

  From: Steve K Speicher <sspeiche@us.ibm.com>
  
  Steven and Forms WG,
  
  I confirm that I am satisfied with this response.
  
  Thanks,
  Steve Speicher
  
  
  Steven Pemberton <xforms-issues@mn.aptest.com> wrote on 06/13/2007 
  04:32:20 PM:
  
  > Steve, 
  > 
  > Thanks for these questions. The WG has resolved to remove 
  > 'mustunderstand' from
  > the spec.
  > 
  > Although your mail doesn't actually suggest a position, would you please 
  reply
  > to this email to confirm that you are satisified with this response?
  > 
  > Many thanks,
  > 
  > For the Forms WG,
  > 
  > Steven Pemberton
  > 
  > > I have a question regarding the validity of the XForm's testsuite case
  > > 3.4.1[1] with respect to mustUnderstand [2].
  > > 
  > > I know that some of these issues have already been raised [3] but 
  wanted
  > > to state that Mozilla XForms is currently not adding support for this 
  [4]
  > > due to some of these issues.
  > > 
  > > We are considering the test case 3.4.1 to be invalid until these 
  issues
  > > are resolved.
  > > 
  > > Here are some of the issues with mustUnderstand:
  > >    - When does it get evaluated?  Must it be handled prior to 
  xforms-ready
  > > or say if it's in a switch/case, only when the case is activated?
  > >    - Can mustUnderstand be manipulated by script? If nodes are 
  dynamically
  > > added to layout but conflicts with mustUnderstand, what error should
  > > occur?
  > > 
  > > Perhaps a better fallback mechanism should be used.  Though I might
  > > propose completely removing mustUnderstand as I don't know of anyone 
  who
  > > has implemented it.  Another thought is to seek feedback or give
  > > requirements to the CDF WG [5], as they are currently dealing with 
  such
  > > issues around mixing namespace documents and content negotiation and
  > > fallback handling of unknown content.
  > > 
  > > Regards,
  > > Steve Speicher
  > > 
  > > [1]
  > > http://www.w3.org/MarkUp/Forms/Test/XForms1.0/Edition2/Chapt3/3.
  > 4/3.4.1/3.4.1.a.xhtml
  > > [2] http://www.w3.org/TR/xforms/slice3.html#module-mustUnderstand
  > > [3] http://lists.w3.org/Archives/Public/www-forms/2002Aug/0149
  > > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=299255
  > > [5] http://www.w3.org/2004/CDF/
  > > 
  > > 
  > > 
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Steve, 
  
  Thanks for these questions. The WG has resolved to remove 'mustunderstand' from
  the spec.
  
  Although your mail doesn't actually suggest a position, would you please reply
  to this email to confirm that you are satisified with this response?
  
  Many thanks,
  
  For the Forms WG,
  
  Steven Pemberton
  
  > I have a question regarding the validity of the XForm's testsuite case
  > 3.4.1[1] with respect to mustUnderstand [2].
  > 
  > I know that some of these issues have already been raised [3] but wanted
  > to state that Mozilla XForms is currently not adding support for this [4]
  > due to some of these issues.
  > 
  > We are considering the test case 3.4.1 to be invalid until these issues
  > are resolved.
  > 
  > Here are some of the issues with mustUnderstand:
  >    - When does it get evaluated?  Must it be handled prior to xforms-ready
  > or say if it's in a switch/case, only when the case is activated?
  >    - Can mustUnderstand be manipulated by script? If nodes are dynamically
  > added to layout but conflicts with mustUnderstand, what error should
  > occur?
  > 
  > Perhaps a better fallback mechanism should be used.  Though I might
  > propose completely removing mustUnderstand as I don't know of anyone who
  > has implemented it.  Another thought is to seek feedback or give
  > requirements to the CDF WG [5], as they are currently dealing with such
  > issues around mixing namespace documents and content negotiation and
  > fallback handling of unknown content.
  > 
  > Regards,
  > Steve Speicher
  > 
  > [1]
  > http://www.w3.org/MarkUp/Forms/Test/XForms1.0/Edition2/Chapt3/3.4/3.4.1/3.4.1.a.xhtml
  > [2] http://www.w3.org/TR/xforms/slice3.html#module-mustUnderstand
  > [3] http://lists.w3.org/Archives/Public/www-forms/2002Aug/0149
  > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=299255
  > [5] http://www.w3.org/2004/CDF/
  > 
  > 
  > 

REPLY 2:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thanks for the comment. This hsa now been fixed.
  
  Best wishes,
  
  Steven Pemberton
  For the FOrms WG
  
  > 1) I thought that the 1.1 spec would drop/deprecate MustUnderstand until it
  > was better defined.  But it is still there.

9.13 Strict and lax schema validation

PROBLEM ID: 87

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree

NOTES:

  Leigh and Erik to document current practice, which is that strict is used if
  there are any top-level element or attribute declarations in a namespace, lax
  otherwise (e.g. if only type libs are applicable to the namespace).  Perhaps
  special case for no namespace instances where temp variables often live.
  
  John's old comments:
  This is actually a pretty nasty problem for us.
  On the one hand, I think the only real answer here is strict. XML schema
  defines
  strict as the default, and you can only go to lax or skip if the schema defines
  processContents to override strictness OR a schema validator *may* switch to
  lax
  mode once a strict failure has happened due to not having a matching element
  declaration (or an association of type via xsi:type).  
  On the other hand, we cannot report as invalid an instance whose *only* failing
  is that there were no matching element and attribute declarations.
  To work around this problem, and also to optimize, I believe we only apply a
  schema to an instance if the root element has a namespace that matches the
  schema target namespace.  The major downside here is that raw data in a SOAP
  envelope tends not to get schema validated. 

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  XForms 1.1 mentions in 4.3.5:
  
       "the node satisfies all applicable XML schema definitions
       (including those associated by [...] an external or an inline
       schema [...])
  
  I would like a precision on what "applicable" means for schema types
  when types are not assigned with xforms:bind or xsi:type. If I do a
  correct job below, then you will see that things are currently not
  clear.
  
  Assume a schema defining types in the:
  
      xmlns:foo="http://example.org/schema/foo"
  
  namespace (that schema does not import other schemas). I import the
  schema into a model with three instances:
  
      <xforms:model schema="foo.xsd">
  
        <xforms:instance id="instance-1">
          <foo:form>
            ...
          </foo:form>
        </xforms:instance>
  
        <xforms:instance id="instance-2">
          <bar:form>
            ...
          </bar:form>
        </xforms:instance>
  
        <xforms:instance id="instance-3">
          <foo:undefined>
            ...
          </foo:undefined>
        </xforms:instance>
  
      </xforms:model>
  
  Assume foo.xsd defines only a complex type for foo:form, but no type
  for foo:undefined, and no type for bar:form (bar maps to a different
  namespace, and there is no schema for "bar").
  
  It seems to me that foo:form for sure has an "applicable" schema
  definition. So no problem here.
  
  Now what's the algorithm for bar:form? It certainly doesn't have any
  schema definition: there is no schema for namespace "bar". So I guess
  this means there is no "applicable" definition for bar:form. However,
  you could decide to recurse the tree and validate further, or not.
  
  Now what about foo:undefined? There is a schema for namespace "foo",
  but none for the type foo:undefined. Does this mean there there is an
  applicable definition or not? Same thing, you could decide to recurse
  the tree and validate further, or not.
  
  Now I shouldn't even have to discuss this in these terms, because XML
  schema provides options already, see "3.10.1 The Wildcard Schema
  Component" in [1].
  
  There are three ways you can process a subtree in schema:
  
      *strict*
  
        There must be a top-level declaration for the item available, or
        the item must have an xsi:type, and the item must be ·valid· as
        appropriate.
  
      *skip*
  
        No constraints at all: the item must simply be well-formed XML.
  
      *lax*
  
        If the item has a uniquely determined declaration available, it
        must be ·valid· with respect to that definition, that is,
        ·validate· if you can, don't worry if you can't.
  
  So it seems to me that here the question is whether we process
  instances with "strict" or "lax" processing (and possibly "skip" as
  well).
  
  XSLT 2.0 solves the problem by providing a "validation" attribute [2]
  which can have value "strict", "lax", and two others ("preserve" and
  "strip") which are probably not relevant here.
  
  XSLT 2.0 also provides a "type" attribute, exclusive with
  "validation". In XForms, we have a similar situation: we can
  explicitly bind a type to the root element of an instance with
  xforms:bind or with xsi:type. If we do, everything is fine. If we
  don't, THEN we want to specify whether we want strict or lax
  validation.
  
  It seems to me then, if my understanding is correct, that there is an
  omission in XForms at this point regarding how validation is
  performed. We should:
  
  1. Explicitly specify whether instance validation is performed in
       "strict" or "lax" mode when no type is assigned to the root element
       of the instance.
  
  2. Ideally, provide an option to specify whether "strict", "lax" or
       even "skip" mode is applied. This could be done with a simple
       attribute on xforms:instance:
  
         <xforms:instance validation="lax">
  
  3. Possibly, also provide the option for "skip" mode, to specifically
       exclude an instance from validation.
  
  Comments on this are of course welcome.
  
  -Erik
  
  [1] http://www.w3.org/TR/xmlschema-1/
  [2] http://www.w3.org/TR/xslt20/#validation
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Erik,
  
  Based on your further explanations as well as explanations from Michael
  Sperberg-McQueen, the working group resolved to adopt the default of lax schema
  processing for initializing the schema validation episode.  Furthermore, the
  applicability of schema definitions is based on this definition with the
  *requirement* to recursively descend when a schema declaration is not found for
  an element.  This mirrors the wording in XSLT 2.0.
  
  The editor's draft now reflects this information in the model element
  definition, and an informative note was added to the revalidate event to point
  to the definition.
  
  Best regards,
  John Boyer
  
  > 
  > All,
  > 
  > XForms 1.1 mentions in 4.3.5:
  > 
  >      "the node satisfies all applicable XML schema definitions
  >      (including those associated by [...] an external or an inline
  >      schema [...])
  > 
  > I would like a precision on what "applicable" means for schema types
  > when types are not assigned with xforms:bind or xsi:type. If I do a
  > correct job below, then you will see that things are currently not
  > clear.
  > 
  > Assume a schema defining types in the:
  > 
  >     xmlns:foo="http://example.org/schema/foo"
  > 
  > namespace (that schema does not import other schemas). I import the
  > schema into a model with three instances:
  > 
  >     <xforms:model schema="foo.xsd">
  > 
  >       <xforms:instance id="instance-1">
  >         <foo:form>
  >           ...
  >         </foo:form>
  >       </xforms:instance>
  > 
  >       <xforms:instance id="instance-2">
  >         <bar:form>
  >           ...
  >         </bar:form>
  >       </xforms:instance>
  > 
  >       <xforms:instance id="instance-3">
  >         <foo:undefined>
  >           ...
  >         </foo:undefined>
  >       </xforms:instance>
  > 
  >     </xforms:model>
  > 
  > Assume foo.xsd defines only a complex type for foo:form, but no type
  > for foo:undefined, and no type for bar:form (bar maps to a different
  > namespace, and there is no schema for "bar").
  > 
  > It seems to me that foo:form for sure has an "applicable" schema
  > definition. So no problem here.
  > 
  > Now what's the algorithm for bar:form? It certainly doesn't have any
  > schema definition: there is no schema for namespace "bar". So I guess
  > this means there is no "applicable" definition for bar:form. However,
  > you could decide to recurse the tree and validate further, or not.
  > 
  > Now what about foo:undefined? There is a schema for namespace "foo",
  > but none for the type foo:undefined. Does this mean there there is an
  > applicable definition or not? Same thing, you could decide to recurse
  > the tree and validate further, or not.
  > 
  > Now I shouldn't even have to discuss this in these terms, because XML
  > schema provides options already, see "3.10.1 The Wildcard Schema
  > Component" in [1].
  > 
  > There are three ways you can process a subtree in schema:
  > 
  >     *strict*
  > 
  >       There must be a top-level declaration for the item available, or
  >       the item must have an xsi:type, and the item must be ?valid? as
  >       appropriate.
  > 
  >     *skip*
  > 
  >       No constraints at all: the item must simply be well-formed XML.
  > 
  >     *lax*
  > 
  >       If the item has a uniquely determined declaration available, it
  >       must be ?valid? with respect to that definition, that is,
  >       ?validate? if you can, don't worry if you can't.
  > 
  > So it seems to me that here the question is whether we process
  > instances with "strict" or "lax" processing (and possibly "skip" as
  > well).
  > 
  > XSLT 2.0 solves the problem by providing a "validation" attribute [2]
  > which can have value "strict", "lax", and two others ("preserve" and
  > "strip") which are probably not relevant here.
  > 
  > XSLT 2.0 also provides a "type" attribute, exclusive with
  > "validation". In XForms, we have a similar situation: we can
  > explicitly bind a type to the root element of an instance with
  > xforms:bind or with xsi:type. If we do, everything is fine. If we
  > don't, THEN we want to specify whether we want strict or lax
  > validation.
  > 
  > It seems to me then, if my understanding is correct, that there is an
  > omission in XForms at this point regarding how validation is
  > performed. We should:
  > 
  > 1. Explicitly specify whether instance validation is performed in
  >      "strict" or "lax" mode when no type is assigned to the root element
  >      of the instance.
  > 
  > 2. Ideally, provide an option to specify whether "strict", "lax" or
  >      even "skip" mode is applied. This could be done with a simple
  >      attribute on xforms:instance:
  > 
  >        <xforms:instance validation="lax">
  > 
  > 3. Possibly, also provide the option for "skip" mode, to specifically
  >      exclude an instance from validation.
  > 
  > Comments on this are of course welcome.
  > 
  > -Erik
  > 
  > [1] http://www.w3.org/TR/xmlschema-1/
  > [2] http://www.w3.org/TR/xslt20/#validation
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

REPLY 2:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Erik,
  
  The working group accepts that we must specify how schemas are applied to
  instance data based on the namespace involved and the available schema
  declarations for that namespace.  The goal will be to document what current
  practice is achieving in effect, rather than a specific means of implementing it
  and rather than adding another feature at this time to provide the form author
  with control over the process.  We intend, with your help of course, to increase
  both form author control and overall flexibility of schema processing in a
  future release of XForms.
  
  Thank you,
  John Boyer
  
  > 
  > All,
  > 
  > XForms 1.1 mentions in 4.3.5:
  > 
  >      "the node satisfies all applicable XML schema definitions
  >      (including those associated by [...] an external or an inline
  >      schema [...])
  > 
  > I would like a precision on what "applicable" means for schema types
  > when types are not assigned with xforms:bind or xsi:type. If I do a
  > correct job below, then you will see that things are currently not
  > clear.
  > 
  > Assume a schema defining types in the:
  > 
  >     xmlns:foo="http://example.org/schema/foo"
  > 
  > namespace (that schema does not import other schemas). I import the
  > schema into a model with three instances:
  > 
  >     <xforms:model schema="foo.xsd">
  > 
  >       <xforms:instance id="instance-1">
  >         <foo:form>
  >           ...
  >         </foo:form>
  >       </xforms:instance>
  > 
  >       <xforms:instance id="instance-2">
  >         <bar:form>
  >           ...
  >         </bar:form>
  >       </xforms:instance>
  > 
  >       <xforms:instance id="instance-3">
  >         <foo:undefined>
  >           ...
  >         </foo:undefined>
  >       </xforms:instance>
  > 
  >     </xforms:model>
  > 
  > Assume foo.xsd defines only a complex type for foo:form, but no type
  > for foo:undefined, and no type for bar:form (bar maps to a different
  > namespace, and there is no schema for "bar").
  > 
  > It seems to me that foo:form for sure has an "applicable" schema
  > definition. So no problem here.
  > 
  > Now what's the algorithm for bar:form? It certainly doesn't have any
  > schema definition: there is no schema for namespace "bar". So I guess
  > this means there is no "applicable" definition for bar:form. However,
  > you could decide to recurse the tree and validate further, or not.
  > 
  > Now what about foo:undefined? There is a schema for namespace "foo",
  > but none for the type foo:undefined. Does this mean there there is an
  > applicable definition or not? Same thing, you could decide to recurse
  > the tree and validate further, or not.
  > 
  > Now I shouldn't even have to discuss this in these terms, because XML
  > schema provides options already, see "3.10.1 The Wildcard Schema
  > Component" in [1].
  > 
  > There are three ways you can process a subtree in schema:
  > 
  >     *strict*
  > 
  >       There must be a top-level declaration for the item available, or
  >       the item must have an xsi:type, and the item must be ?valid? as
  >       appropriate.
  > 
  >     *skip*
  > 
  >       No constraints at all: the item must simply be well-formed XML.
  > 
  >     *lax*
  > 
  >       If the item has a uniquely determined declaration available, it
  >       must be ?valid? with respect to that definition, that is,
  >       ?validate? if you can, don't worry if you can't.
  > 
  > So it seems to me that here the question is whether we process
  > instances with "strict" or "lax" processing (and possibly "skip" as
  > well).
  > 
  > XSLT 2.0 solves the problem by providing a "validation" attribute [2]
  > which can have value "strict", "lax", and two others ("preserve" and
  > "strip") which are probably not relevant here.
  > 
  > XSLT 2.0 also provides a "type" attribute, exclusive with
  > "validation". In XForms, we have a similar situation: we can
  > explicitly bind a type to the root element of an instance with
  > xforms:bind or with xsi:type. If we do, everything is fine. If we
  > don't, THEN we want to specify whether we want strict or lax
  > validation.
  > 
  > It seems to me then, if my understanding is correct, that there is an
  > omission in XForms at this point regarding how validation is
  > performed. We should:
  > 
  > 1. Explicitly specify whether instance validation is performed in
  >      "strict" or "lax" mode when no type is assigned to the root element
  >      of the instance.
  > 
  > 2. Ideally, provide an option to specify whether "strict", "lax" or
  >      even "skip" mode is applied. This could be done with a simple
  >      attribute on xforms:instance:
  > 
  >        <xforms:instance validation="lax">
  > 
  > 3. Possibly, also provide the option for "skip" mode, to specifically
  >      exclude an instance from validation.
  > 
  > Comments on this are of course welcome.
  > 
  > -Erik
  > 
  > [1] http://www.w3.org/TR/xmlschema-1/
  > [2] http://www.w3.org/TR/xslt20/#validation
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

9.14 XForms 1.1 WD last call comments from CDF WG

PROBLEM ID: 129

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  We have resolved to remove mustunderstand.
  Two other last call comments also requested removal of this optional module
  because it is not widely implemented as an optional module; the reason, in turn,
  is that it appears to be a CDF problem, not something that can be solved by
  XForms alone. 

ORIGINAL MESSAGE:

  From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com>
  
  CDF07 - mustUnderstand module not defined well enough, recommend removing.
  Delete
  Rationale: The CDF WG feels that this module should be removed.
  Here are some of the issues with mustUnderstand:
     - When does it get evaluated?  Must it be handled prior to xforms-ready
  or say if it's in a switch/case, only when the case is activated?
     - Can mustUnderstand be manipulated by script? If nodes are dynamically
  added to layout but conflicts with mustUnderstand, what error should occur?
  Perhaps a better fallback mechanism should be used.  We.d recommend to seek
  feedback or give requirements to the CDF WG, as we are currently dealing
  with such issues around mixing namespace documents, content identification,
  content negotiation and fallback handling of unknown content.
  

FOLLOWUP 1:

  From: member-cdf-request@w3.org
  
  *** NOTE: ***
  
      Your message was sent from an address which is not on the list
      of people who are authorized to post to this mailing list.
      Therefore, your message has been forwarded to the list maintainer
      for manual processing.
  
      If you do not see your message appear on the list or in the
      mailing list archives within a few business days, you may wish
      to contact the mailing list maintainer to investigate the delay.
  
      -- W3C Postmaster
         http://www.w3.org/Mail/
  
  your message follows:
  ----------------------------------------------------------------------------
  
  
  Thank you for the comment. The XForms WG has resolved to remove the
  mustunderstand model as you suggest.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  
  > CDF07 - mustUnderstand module not defined well enough, recommend removing.
  > Delete
  > Rationale: The CDF WG feels that this module should be removed.
  > Here are some of the issues with mustUnderstand:
  >    - When does it get evaluated?  Must it be handled prior to xforms-ready
  > or say if it's in a switch/case, only when the case is activated?
  >    - Can mustUnderstand be manipulated by script? If nodes are dynamically
  > added to layout but conflicts with mustUnderstand, what error should occur?
  > Perhaps a better fallback mechanism should be used.  We.d recommend to seek
  > feedback or give requirements to the CDF WG, as we are currently dealing
  > with such issues around mixing namespace documents, content identification,
  > content negotiation and fallback handling of unknown content.
  > 
  > 
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thank you for the comment. The XForms WG has resolved to remove the
  mustunderstand model as you suggest.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  
  > CDF07 - mustUnderstand module not defined well enough, recommend removing.
  > Delete
  > Rationale: The CDF WG feels that this module should be removed.
  > Here are some of the issues with mustUnderstand:
  >    - When does it get evaluated?  Must it be handled prior to xforms-ready
  > or say if it's in a switch/case, only when the case is activated?
  >    - Can mustUnderstand be manipulated by script? If nodes are dynamically
  > added to layout but conflicts with mustUnderstand, what error should occur?
  > Perhaps a better fallback mechanism should be used.  We.d recommend to seek
  > feedback or give requirements to the CDF WG, as we are currently dealing
  > with such issues around mixing namespace documents, content identification,
  > content negotiation and fallback handling of unknown content.
  > 
  > 

9.15 Section 9

PROBLEM ID: 154

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: No Response

NOTES:

  Another LC comment (#55) also requested this.
  This is only a modestly substantive change w.r.t. the last call document.
  XForms has always supported src, and we tried one way of expressing that more
  clearly in LC; we now express it much more clearly by adopting it into XForms
  from the host language.  This reflects how implementers are actually processing
  it, and it satifies this LC comment, and it helped to resolve the I18N group's
  issue with whether or not we support all of xsd:anyURI (which could not be
  stated definitively while src remained a host language construct).  So we do
  not expect any objection to this change.

ORIGINAL MESSAGE:

  From: aaronr@us.ibm.com
  
  Full_Name: Aaron Reed
  Submission from: (NULL) (32.97.110.142)
  Submitted by: boyerj
  
  
  Date: Mon, 30 Apr 2007 23:56:50 +0200
  To: www-forms-editor@w3.org
  Subject: Section 9
  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  15) Section 4.2.1 - item #2 - it mentions @resource but not what happens if
  there is a host-language defined linking attribute.
  

FOLLOWUP 1:

  From: John Boyer <xforms-issues@aptest.com>
  
  Hi Aaron,
  
  The working group agreed with you that it was better to specify src on instance
  as part of XForms rather than relying upon the host language to add it.  This
  was viewed as being consistent with our earlier addition of the id attribute to
  the common attributes (i.e. we agreed it was generally true that if an attribute
  is needed to produce some core required behavior, then the attribute should
  appear in the XForms schema).
  
  You can find the revised text with diff marks in the editor's draft available
  from the Forms WG website at
  http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-model-instance
  
  Please let us know if you have any concerns about this resolution.
  
  Thanks,
  John Boyer
  
  > Date: Mon, 30 Apr 2007 23:56:50 +0200
  > To: www-forms-editor@w3.org
  > Subject: src attribute on instance
  > From: "Aaron Reed" <aaronr@us.ibm.com>
  > 
  > 15) Section 4.2.1 - item #2 - it mentions @resource but not what happens if
  > there is a host-language defined linking attribute.
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  The working group agreed with you that it was better to specify src on instance
  as part of XForms rather than relying upon the host language to add it.  This
  was viewed as being consistent with our earlier addition of the id attribute to
  the common attributes (i.e. we agreed it was generally true that if an attribute
  is needed to produce some core required behavior, then the attribute should
  appear in the XForms schema).
  
  You can find the revised text with diff marks in the editor's draft available
  from the Forms WG website at
  http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-model-instance
  
  Please let us know if you have any concerns about