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

9.16 XForms document versioning

PROBLEM ID: 104

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

NOTES:

  This is only modestly substantive in that it changed how version worked.  We do
  not expect an objection since the same description appears in XForms 1.0 Third
  Edition, which was accepted as a Recommendation.

ORIGINAL MESSAGE:

  From: "Mark Birbeck" <mark.birbeck@x-port.net>
  
  
  Hello,
  
  I'd like to suggest that we have a version attribute that can be used
  on any element in a host language. This would therefore be a global
  attribute in the XForms namespace, and might be used as follows:
  
     <html xf:version="1.1">
       ...
     </html>
  
  My feeling is that this attribute is less about enforcing behaviour of
  processors, and more about providing a clear indication to authors
  which type of document they are dealing with.
  
  For example, if a form contains a submission that uses the new
  xf:resource attribute or element, it may not be immediately obvious to
  a new author as they start to learn XForms, that this is not supported
  in all processors. Rather than having a flurry of emails on one or
  other list saying that some example doesn't work, I think we should
  encourage authors to indicate what standard is being used by a form.
  
  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.
  

FOLLOWUP 1:

  From: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
  
  There's a typo here;  The "a again" should simply be removed.
  I mistyped this in the text sent to Ulrich.
  Leigh. 
  
  -----Original Message-----
  From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf Of Ulrich Nicolas Lissé
  Sent: Thursday, June 14, 2007 1:11 PM
  To: mark.birbeck@x-port.net
  Cc: www-forms@w3.org; www-forms-editor@w3.org
  Subject: Re: XForms document versioning (PR#104)
  
  
  Mark,
  
  we changed section 3.3.1 to default model version to empty, and defined empty to
  mean that the processor gets to choose the version. If no version chosen is
  available, the xforms-version-exception is dispatched to the default model. The
  declaration on the default model is used to make the choice. Later models may
  offer declarations of model version but xforms-version-exception is a gain
  dispatched to the default model if their declarations are incompatible with the
  version chosen.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  > Hello,
  > 
  > I'd like to suggest that we have a version attribute that can be used
  > on any element in a host language. This would therefore be a global
  > attribute in the XForms namespace, and might be used as follows:
  > 
  >    <html xf:version="1.1">
  >      ...
  >    </html>
  > 
  > My feeling is that this attribute is less about enforcing behaviour of
  > processors, and more about providing a clear indication to authors
  > which type of document they are dealing with.
  > 
  > For example, if a form contains a submission that uses the new
  > xf:resource attribute or element, it may not be immediately obvious to
  > a new author as they start to learn XForms, that this is not supported
  > in all processors. Rather than having a flurry of emails on one or
  > other list saying that some example doesn't work, I think we should
  > encourage authors to indicate what standard is being used by a form.
  > 
  > 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 changed section 3.3.1 to default model version to empty, and defined empty to
  mean that the processor gets to choose the version. If no version chosen is
  available, the xforms-version-exception is dispatched to the default model. The
  declaration on the default model is used to make the choice. Later models may
  offer declarations of model version but xforms-version-exception is a gain
  dispatched to the default model if their declarations are incompatible with the
  version chosen.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  > Hello,
  > 
  > I'd like to suggest that we have a version attribute that can be used
  > on any element in a host language. This would therefore be a global
  > attribute in the XForms namespace, and might be used as follows:
  > 
  >    <html xf:version="1.1">
  >      ...
  >    </html>
  > 
  > My feeling is that this attribute is less about enforcing behaviour of
  > processors, and more about providing a clear indication to authors
  > which type of document they are dealing with.
  > 
  > For example, if a form contains a submission that uses the new
  > xf:resource attribute or element, it may not be immediately obvious to
  > a new author as they start to learn XForms, that this is not supported
  > in all processors. Rather than having a flurry of emails on one or
  > other list saying that some example doesn't work, I think we should
  > encourage authors to indicate what standard is being used by a form.
  > 
  > 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.
  > 
  > 

9.17 xsi:type

PROBLEM ID: 85

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

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  XForms mentions in a few places support for xsi:type, in "4.3.5 The
  xforms-revalidate Event", "6.2.1 Atomic Datatype", and "7.11.4 The id()
  Function".
  
  It is not clear to me if an implementation must support xsi:type
  attributes on elements when there is no xforms:model/@schema defined, or
  no inline schema.
  
  It is my understanding that the "type" model item property does support
  XML Schema and XForms built-in data types even in the absence of a
  schema. But is this true as well of xsi:type attributes?
  
  -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,
  
  Yes, it is true that xsi:type attributes are supported even when there are no
  form-declared schema in the form.  This is because the validation test in
  Section 4.3.4 states that validity is based on *all applicable schema
  definitions* including those coming from xsi:type. Due to the XML Schema
  recommendation, an existing xsi:type declaration is, by default, applicable to
  element validity.  In general, we follow all rules of XML schema except those
  that are explicitly mentioned as not being supported.  Section 6.2 provides the
  only mention of schema rules we do not follow (and are allowed not to follow). 
  In that section, we say that schema rules are not applicable if they come from a
  schema indicated by xsi:schemaLocation or xsi:noNamespaceSchemaLocation.
  
  In today's WG telecon, you indicated it would be satisfactory to have a note in
  the spec to clarify that xsi:type is applicable even if there are no declared
  schemas, and that note appears in Section 4.3.4 of the editor's draft of the
  spec available from the WG home page. 
  
  Thank you,
  John Boyer
  
  > 
  > All,
  > 
  > XForms mentions in a few places support for xsi:type, in "4.3.5 The
  > xforms-revalidate Event", "6.2.1 Atomic Datatype", and "7.11.4 The id()
  > Function".
  > 
  > It is not clear to me if an implementation must support xsi:type
  > attributes on elements when there is no xforms:model/@schema defined, or
  > no inline schema.
  > 
  > It is my understanding that the "type" model item property does support
  > XML Schema and XForms built-in data types even in the absence of a
  > schema. But is this true as well of xsi:type attributes?
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

9.18 CDF04 - 3.3 The XForms Core Module missing reference to compound document profile.

PROBLEM ID: 127

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

ORIGINAL MESSAGE:

  From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com>
  
  Change
  "Note that the presence of foreign namespaced elements is subject to the
  definition of the containing document profile. "
  To
  "Note that the presence of foreign namespaced elements is subject to the
  definition of the containing or compound document profile. "
  Rationale: Provides clarification for compound document profiles.
  

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, 
  
  Thank you for this feedback.  The working group has agreed to this change, and
  the specification will be amended as requested in the last call comment (copied
  below).  An editor's draft of changes is available from the Forms WG homepage,
  and a version containing this change will be available by tomorrow.
  
  Thanks,
  John Boyer
  
  > Change
  > "Note that the presence of foreign namespaced elements is subject to the
  > definition of the containing document profile. "
  > To
  > "Note that the presence of foreign namespaced elements is subject to the
  > definition of the containing or compound document profile. "
  > Rationale: Provides clarification for compound document profiles.
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Kevin, 
  
  Thank you for this feedback.  The working group has agreed to this change, and
  the specification will be amended as requested in the last call comment (copied
  below).  An editor's draft of changes is available from the Forms WG homepage,
  and a version containing this change will be available by tomorrow.
  
  Thanks,
  John Boyer
  
  > Change
  > "Note that the presence of foreign namespaced elements is subject to the
  > definition of the containing document profile. "
  > To
  > "Note that the presence of foreign namespaced elements is subject to the
  > definition of the containing or compound document profile. "
  > Rationale: Provides clarification for compound document profiles.
  > 
  > 

10. Multi-issue

10.1 Re: XForms 1.1 spec editor's drafts now available on public page

PROBLEM ID: 91

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

ORIGINAL MESSAGE:

  From: =?iso-8859-1?Q?Ulrich_Nicolas_Liss=E9?= <unl@dreamlab.net>
  
  
  Hello John,
  
  great work. Alas, some typos and other minor issues popped up during
  fine reading. Maybe some of these are contained in XForms 1.0 editions
  too, but I didn't check this.
  
  "3.3 The XForms Core Module"
  
  The table contains a wrong attribute definition for the submission
  element. It says: "... method
  ("post"|"get"|"put"|delete|"form-data-post"|"urlencoded-post"|QNameButNotNCNAME)
  
  ...."
  
  The word delete should have double quotes, since it is a fixed value
  instead of a type.
  
  "3.3.1 The model Element"
  
  The sentence "This element is not an XForms Action, and has no
  predefined behavior event-based behavior." has too many behaviors ;-)
  Remove "behavior" after "predefined".
  
  "3.3.2 The instance Element"
  
  In the description of the resource attribute there is the sentence "If
  the host language may treat failure to traverse the link as an exception
  (4.5.2 The xforms-link-exception Event).", which is not really
  understandable. Remove "If".
  
  "4.5.5 The xforms-version-exception Event"
  
  For this event's context information a property "errorinformation" is
  defined. Shouldn't this be named "error-information" instead to be
  consistent with the naming scheme of other event's properties (like
  "resource-uri" or "error-message")?
  
  "4.6.1 For input, secret, textarea, range, or upload Controls"
  
  The first bullet says "... has the "incremental="true" setting ...", the
  second "... does not have the "incremental=true" setting". The double
  quotes for the incremental attribute have to be fixed, and it should be
  set in <code>-markup.
  
  "4.6.3 For select or select1 Controls"
  
  Same as above.
  
  "7.6 The XForms Function Library"
  
  Replace "xforms-binding exception" with "xforms-binding-exception" in
  the last sentence.
  
  "7.8.5 The index() Function"
  
  The second sentence "if the specified argument ..." should start uppercase.
  
  "7.9.4 The digest() Function"
  
  All three expamples for this extension function still show
  "hash-encode". Replace with "digest".
  
  "8.1.5 The output Element"
  
  There are two Description paragraphs provided here. They are similar but
  not identical. The second one seems more accurate, so please delete the
  first one.
  
  "8.3.1 The filename Element"
  
  In the description of a then following example
  "mail/attachment@filename" and "mail/attachment@mediatype" refer to
  attribute nodes. The correct XPath syntax "mail/attachment/@filename"
  and "mail/attachment/@mediatype" should be used.
  
  "9.3.1 The repeat Element"
  
  In the paragraph after the special attributes description the second
  sentence "if an element of the collection ..." should start uppercase.
  
  "9.3.5 The insert Action"
  
  The 5th example ("Inserting into a repeat, whether or not it is empty")
  refers to "repeat R". In the code snippet there is a call to index()
  function in <xf:insert ... at="index('R')"/> as well as a <xf:setfocus
  control="R"/>. However, the repeat is missing id="R" which might confuse
  readers. Maybe it could even be renamed to something more
  self-explanatory, e.g. "PurchaseOrderRepeat".
  
  "9.3.7 The setindex Element"
  
  In the paragraph after the special attributes description the third
  sentence "if the index evaluates to NaN ..." should start uppercase.
  
  "9.3.8 Repeat Processing"
  
  In list item 2. the second sentence "if the initial startindex ..."
  should start uppercase.
  
  "10.10.2 Processing of the load Action"
  
  In the second paragraph "... link between th load element and the remote
  resource" replace "th " with "the ".
  
  "10.15 Iteration of XForms Actions"
  
  I don't speak English natively, but the sentence "Counter and Accumlator
  Variables are Created in Instance Data to Sum a Selection of Values
  Chosen by the User" hurts my eyes. Shouldn't this simply be "Counter and
  accumlator variables are created in instance data to sum a selection of
  values chosen by the user." ??
  
  "11.2 The xforms-submit Event"
  
  In "The response returned from the submission is applied as follows:"
  list, the second bullet's second sentence "if the parse fails ..."
  should start uppercase.
  
  "11.19.3 SOAP HTTP Binding"
  
  In the second list the first bullet "the Content-type HTTP header is
  change to text/xml" should be changed to contain "changed".
  
  Regards,
  Uli.
  -- 
  Ulrich Nicolas Lissé
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Uli,
  
  Thanks for spotting these issues.  Resolutions are given in the inline comments.
   Please see the editor's draft of XForms 1.1 available from the Forms WG home
  page and let us know if you have any further concerns about these issues.
  
  Thanks,
  John Boyer
  
  > 
  > Hello John,
  > 
  > great work. Alas, some typos and other minor issues popped up during
  > fine reading. Maybe some of these are contained in XForms 1.0 editions
  > too, but I didn't check this.
  > 
  > "3.3 The XForms Core Module"
  > 
  > The table contains a wrong attribute definition for the submission
  > element. It says: "... method
  > ("post"|"get"|"put"|delete|"form-data-post"|"urlencoded-post"|QNameButNotNCNAME)
  > 
  > ...."
  
  Fixed.
  
  > 
  > The word delete should have double quotes, since it is a fixed value
  > instead of a type.
  > 
  > "3.3.1 The model Element"
  > 
  > The sentence "This element is not an XForms Action, and has no
  > predefined behavior event-based behavior." has too many behaviors ;-)
  > Remove "behavior" after "predefined".
  > 
  
  The whole phrase containing the error is removed as it is ambiguous even once
  the error is corrected.
  
  > "3.3.2 The instance Element"
  > 
  > In the description of the resource attribute there is the sentence "If
  > the host language may treat failure to traverse the link as an exception
  > (4.5.2 The xforms-link-exception Event).", which is not really
  > understandable. Remove "If".
  
  Fixed via changes to allow the src attribute into XForms directly (as opposed to
  being added by the host language).
  
  > 
  > "4.5.5 The xforms-version-exception Event"
  > 
  > For this event's context information a property "errorinformation" is
  > defined. Shouldn't this be named "error-information" instead to be
  > consistent with the naming scheme of other event's properties (like
  > "resource-uri" or "error-message")?
  
  Fixed.
  
  > 
  > "4.6.1 For input, secret, textarea, range, or upload Controls"
  > 
  > The first bullet says "... has the "incremental="true" setting ...", the
  > second "... does not have the "incremental=true" setting". The double
  > quotes for the incremental attribute have to be fixed, and it should be
  > set in <code>-markup.
  > 
  
  Fixed.
  
  > "4.6.3 For select or select1 Controls"
  > 
  > Same as above.
  
  Fixed.
  
  > 
  > "7.6 The XForms Function Library"
  > 
  > Replace "xforms-binding exception" with "xforms-binding-exception" in
  > the last sentence.
  
  Fixed.
  
  > 
  > "7.8.5 The index() Function"
  > 
  > The second sentence "if the specified argument ..." should start uppercase.
  > 
  
  Fixed.
  
  > "7.9.4 The digest() Function"
  > 
  > All three expamples for this extension function still show
  > "hash-encode". Replace with "digest".
  > 
  
  Good catch.  Fixed.
  
  > "8.1.5 The output Element"
  > 
  > There are two Description paragraphs provided here. They are similar but
  > not identical. The second one seems more accurate, so please delete the
  > first one.
  > 
  
  Fixed.
  
  > "8.3.1 The filename Element"
  > 
  > In the description of a then following example
  > "mail/attachment@filename" and "mail/attachment@mediatype" refer to
  > attribute nodes. The correct XPath syntax "mail/attachment/@filename"
  > and "mail/attachment/@mediatype" should be used.
  > 
  
  Good catch. Fixed.
  
  > "9.3.1 The repeat Element"
  > 
  > In the paragraph after the special attributes description the second
  > sentence "if an element of the collection ..." should start uppercase.
  > 
  
  Fixed.
  
  > "9.3.5 The insert Action"
  > 
  > The 5th example ("Inserting into a repeat, whether or not it is empty")
  > refers to "repeat R". In the code snippet there is a call to index()
  > function in <xf:insert ... at="index('R')"/> as well as a <xf:setfocus
  > control="R"/>. However, the repeat is missing id="R" which might confuse
  > readers. Maybe it could even be renamed to something more
  > self-explanatory, e.g. "PurchaseOrderRepeat".
  > 
  
  Added id="R"
  
  > "9.3.7 The setindex Element"
  > 
  > In the paragraph after the special attributes description the third
  > sentence "if the index evaluates to NaN ..." should start uppercase.
  > 
  
  Fixed.
  
  > "9.3.8 Repeat Processing"
  > 
  > In list item 2. the second sentence "if the initial startindex ..."
  > should start uppercase.
  > 
  
  Fixed.
  
  > "10.10.2 Processing of the load Action"
  > 
  > In the second paragraph "... link between th load element and the remote
  > resource" replace "th " with "the ".
  
  Fixed.
  
  > 
  > "10.15 Iteration of XForms Actions"
  > 
  > I don't speak English natively, but the sentence "Counter and Accumlator
  > Variables are Created in Instance Data to Sum a Selection of Values
  > Chosen by the User" hurts my eyes. Shouldn't this simply be "Counter and
  > accumlator variables are created in instance data to sum a selection of
  > values chosen by the user." ??
  >
  
  You're right.  It's not a title, so it shouldn't be in title case.
  Fixed.
   
  > "11.2 The xforms-submit Event"
  > 
  > In "The response returned from the submission is applied as follows:"
  > list, the second bullet's second sentence "if the parse fails ..."
  > should start uppercase.
  > 
  
  Fixed.
  
  > "11.19.3 SOAP HTTP Binding"
  > 
  > In the second list the first bullet "the Content-type HTTP header is
  > change to text/xml" should be changed to contain "changed".
  
  Fixed.
  
  > 
  > Regards,
  > Uli.
  > -- 
  > Ulrich Nicolas Liss銾 
  > 
  > 

11. Steven.prefs

12. Submission

12.1 [LC] 11.1 The submission Element

PROBLEM ID: 76

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

NOTES:

  The changes are mostly editorial.  The substantive change was the change of name
  of the 'verb' element to 'method'.  As explained in another LC comment, and also
  evident here, the name 'verb' was confusing and we were unable to find a current
  normative reference for that name, so the same features were renamed 'method'. 
  No objection is expected due to the increase of clarity and because the name
  change does not invalidate any prior experience implementing the feature under
  the old name.
  
  Detailed notes:
  1) It has now been clarified @resource is the attribute to use going forward
  and
  that action, while still supported, is deprecated.  The resource attribute
  cannot be an XPathExpr because it is the new 'action' attribute and because
  that
  would be inconsistent with use of @resource in other elements (load, instance).
  
  Moreover, the resource child element was added because this is consistent with
  how we have allowed XPaths to override literal attributes throughout XForms
  1.1.
  
  
  2) The allowable values of method were specified, but only in the core
  structure
  chapter, not in the submission module chapter.  This has been corrected by
  placing the table providing the overview of attributes and element content for
  the submission element in the submission chapter.
  
  3) We agree that the verb element/attribute was confusing, and we have
  restructured the 'method' to take over the functionality we intended for verb. 
  This has significantly clarified the submission protocol operation and
  submission data serialization.
  
  4) We agree that the attributes represent differnt parts of speech, but this is
  generally true of all attributes of submission, and rationalizing them is
  actually impossible since some are inherited from XSLT output, which has the
  same issue.  Also, part of eliminating 'verb' involved deverbifying serialize;
  it has become serialization.  In general, it seems that the real issue here is
  that the name 'relevant' is perhaps not as good a name for what it names as are
  validate and serialization (despite their being different parts of speech). 
  The
  attribute controls whether or not the relevant MIP of data nodes are applied by
  submission, which normally prunes from serialization data nodes whose relevant
  MIP is false. Other names have been considered, such as 'prunenonrelevantnodes'
  and 'prune', but these are either exacting but unwieldy or ambiguous.  The name
  'relevant' was selected because it is clearly connected to the issue of
  relevance, and as an attribute of submission, it seemed it would be easier for
  readers to understand that it controlled the interaction between submission and
  the relevant MIP.
  
  5) All of the optional attributes of submission now have their default values
  or
  behaviors specified.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#submit-submission-element
  
  Resource attribute
  
  The reader needs more help in deciding whether to use this or
  @action. This is sure to lead to confusion. In fact why not do away
  with the resource child and let this attribute be a value?
  
  	 <submission resource="concat('http://example.com/details/', country,  
  '/', city, '/')" ... />
  
  @method
  	The allowable values should be listed.
  
  @verb
  	Very difficult to understand what this does, and what a verb is. What
  are the allowable vaues?
  
  Note that the names @validate and @serialize are verbs, while @relevant is  
  an adjective (untidy difference).
  
  All the attributes need types and default values here.
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  Thank you for submitting the last call comments below.  The working group has
  resolved the issues as described by the inline comments below.  Please see the
  editor's draft of XForms 1.1 available from the Forms WG home page and let us
  know if you have any further concerns about these issues.
  
  Thank you,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#submit-submission-element
  > 
  > Resource attribute
  > 
  > The reader needs more help in deciding whether to use this or
  > @action. This is sure to lead to confusion. In fact why not do away
  > with the resource child and let this attribute be a value?
  > 
  > 	 <submission resource="concat('http://example.com/details/', country,  
  > '/', city, '/')" ... />
  > 
  
  1) It has now been clarified @resource is the attribute to use going forward and
  that action, while still supported, is deprecated.  The resource attribute
  cannot be an XPathExpr because it is the new 'action' attribute and because that
  would be inconsistent with use of @resource in other elements (load, instance). 
  Moreover, the resource child element was added because this is consistent with
  how we have allowed XPaths to override literal attributes throughout XForms 1.1.
  
  
  > @method
  > 	The allowable values should be listed.
  > 
  
  2) The allowable values of method were specified, but only in the core structure
  chapter, not in the submission module chapter.  This has been corrected by
  placing the table providing the overview of attributes and element content for
  the submission element in the submission chapter.
  
  > @verb
  > 	Very difficult to understand what this does, and what a verb is. What
  > are the allowable vaues?
  > 
  
  3) We agree that the verb element/attribute was confusing, and we have
  restructured the 'method' to take over the functionality we intended for verb. 
  This has significantly clarified the submission protocol operation and
  submission data serialization.
  
  > Note that the names @validate and @serialize are verbs, while @relevant is  
  > an adjective (untidy difference).
  > 
  
  4) We agree that the attributes represent differnt parts of speech, but this is
  generally true of all attributes of submission, and rationalizing them is
  actually impossible since some are inherited from XSLT output, which has the
  same issue.  Also, part of eliminating 'verb' involved deverbifying serialize;
  it has become serialization.  In general, it seems that the real issue here is
  that the name 'relevant' is perhaps not as good a name for what it names as are
  validate and serialization (despite their being different parts of speech).  The
  attribute controls whether or not the relevant MIP of data nodes are applied by
  submission, which normally prunes from serialization data nodes whose relevant
  MIP is false. Other names have been considered, such as 'prunenonrelevantnodes'
  and 'prune', but these are either exacting but unwieldy or ambiguous.  The name
  'relevant' was selected because it is clearly connected to the issue of
  relevance, and as an attribute of submission, it seemed it would be easier for
  readers to understand that it controlled the interaction between submission and
  the relevant MIP.
  
  > All the attributes need types and default values here.
  
  5) All of the optional attributes of submission now have their default values or
  behaviors specified.
  

12.2 [LC1.1] Section 11.7 'verb'

PROBLEM ID: 103

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

NOTES:

  Mostly editorial changes.  The substantive change was the change of name
  of the 'verb' element to 'method'.  As explained in three other LC comments, and
  also evident here, the name 'verb' was confusing and we were unable to find a
  current normative reference for that name, so the same features were renamed
  'method'.  No objection is expected due to the increase of clarity and because
  the name change does not invalidate any prior experience implementing the
  feature under the old name.
  
  Detailed notes:
  1) Eliminated verb in favor of better use of method attr/elem pair.
  
  2) Based on elimination of verb in favor of method attr/elem, we also switched
  to having a serialization attr, whose default is determined by the method. 
  This
  allowed us to clean up the table substantially.  
  
  3) Verb is eliminated.  As in XForms 1.0, the *method* setting would be post or
  urlencoded-post, both of which would result in an HTTP method (as defined in
  RFC
  2616) of POST.  For the HTTP scheme, the method is what we were referring to as
  the "verb".  What we meant there was the protocol operation, which under the
  HTTP protocol is the "method".
  
  4) Now that we have switched to using 'method', it is clear that there is no
  default.
  
  5) The element has been renamed 'method', but error reported here is fixed.
  

ORIGINAL MESSAGE:

  From: "Steve K Speicher" <sspeiche@us.ibm.com>
  
  
  This is a LC comment regarding the "verb" section of
  http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-verb
  and likewise references in
  http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-options
  
  1) I can not find a clear definition or normative reference, to what a
  "verb" is.
  
  2)
  Section states:
           "default value is determined based on the URI scheme and the
  method attribute using the rules in 11.9 Submission Options. "
  Comment:
           Looking in 11.9, I can not find any clear rules for processing.
  Only a reference to the "submission" column, which does not define a
  string literal that can be used for the value of the element/attribute of
  verb.  I'd recommend clarifying the table either by adding a new "Verb"
  column and string literals that are valid.
  
  3)
  Section states:
           "For example, under the http and https schemes, the methods post
  and urlencoded-post correspond to the verb POST"
  Comment:
           Does this imply that if action="http://someurl" that verb="post"
  and if action="https://someurl" then verb="urlencoded-post"?
  
  4)
  Section states:
           "If given, the verb attribute overrides the default verb used in
  submission"
  Comment:
           What is the default?  Perhaps it is given in the table in 11.9 but
  I'm unable to clearly map the values
  
  5) Editorial
  Section states:
           "The submission element can optionally *have* a child element
  named verb"
  missing word *have*
  
  Thanks,
  Steve Speicher
  IBM SWG, Software Standards
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steve,
  
  Thank you for the last call comments below, all of which have been accepted and
  implemented in the ways described in the inline comments below.  Please see the
  editor's draft available from the Forms WG website and let us know if you have
  any further concerns.
  
  Best regards,
  John Boyer
  
  > 
  > This is a LC comment regarding the "verb" section of
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-verb
  > and likewise references in
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-options
  > 
  > 1) I can not find a clear definition or normative reference, to what a
  > "verb" is.
  > 
  
  We eliminated verb in favor of better use of method attr/elem pair since method
  is normatively defined by RFC 2616.
  
  > 2)
  > Section states:
  >          "default value is determined based on the URI scheme and the
  > method attribute using the rules in 11.9 Submission Options. "
  > Comment:
  >          Looking in 11.9, I can not find any clear rules for processing.
  > Only a reference to the "submission" column, which does not define a
  > string literal that can be used for the value of the element/attribute of
  > verb.  I'd recommend clarifying the table either by adding a new "Verb"
  > column and string literals that are valid.
  > 
  
  Based on elimination of verb in favor of method attr/elem, we also switched
  to having a serialization attr, whose default is determined by the method. 
  This
  allowed us to clean up several places in the submission chapter, esp. the table
  in 11.9, so that the relationship between the method, the default serialization
  and the submission protocol operation (e.g. the http method) should now be clear
  .  
  
  
  > 3)
  > Section states:
  >          "For example, under the http and https schemes, the methods post
  > and urlencoded-post correspond to the verb POST"
  > Comment:
  >          Does this imply that if action="http://someurl" that verb="post"
  > and if action="https://someurl" then verb="urlencoded-post"?
  > 
  
  3) Verb is eliminated.  As in XForms 1.0, the *method* setting would be post or
  urlencoded-post, both of which would result in an HTTP method (as defined in
  RFC
  2616) of POST.  For the HTTP scheme, the method is what we were referring to as
  the "verb".  What we meant there was the protocol operation, which under the
  HTTP protocol is the "method".
  
  > 4)
  > Section states:
  >          "If given, the verb attribute overrides the default verb used in
  > submission"
  > Comment:
  >          What is the default?  Perhaps it is given in the table in 11.9 but
  > I'm unable to clearly map the values
  > 
  
  4) Now that we have switched to using 'method' instead of 'verb', it is clear
  that there is no default (specifying the submission method is mandatory).
  
  
  > 5) Editorial
  > Section states:
  >          "The submission element can optionally *have* a child element
  > named verb"
  > missing word *have*
  > 
  
  5) The child element has been renamed 'method', but error reported here is
  fixed.
  
  
  > Thanks,
  > Steve Speicher
  > IBM SWG, Software Standards
  > 
  > 
  > 

12.3 Required but empty

PROBLEM ID: 83

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

NOTES:

  Rejected because the definition of empty string is clear and has to be the same
  as is defined in XML Schema for validation purposes and in XPath for
  calculation
  processing purposes.

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  I have a doubt about the meaning of "empty" in the wording "required but
  empty" (which appears in 11.2.3 and 4.3.5).
  
  It seems that "empty" could either mean:
  
  1. A zero-length string (clear technical interpretation)
  2. A string empty as per #1 above, or a string with only white-space
       (human-friendly interpretation)
  
  Imagine a user entering by error a space in an input field. Visually,
  with most agents (typically web browsers), you can't tell whether the
  field is empty according to #1 above, or contains white space. So to the
  user, the field is "empty".
  
  But if the XForms implementation implements #1, then this visually empty
  field will be considered non-empty, and pass submission even if required.
  
  This would favor an interpretation of "empty" where not only strictly
  empty strings are "empty", but also strings containing only white space.
  
  At the very least, the spec should say whether it means #1, #2, or
  implementation-dependent.
  
  -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,
  
  The working group considered this issue and felt that the definition of empty
  string as being zero characters (as opposed to zero non-whitespace characters)
  was well-known enough not to need clarification and that this is the definition
  that we should be using for the 'required' MIP as it is consistent with the
  notion of empty string in XML schema and XPath.
  
  We do agree that there are forms in which one might not want to distinguish
  empty from containing only whitespace.  We believe this can be done via the
  constraint MIP, though we agree with your statement in [1] that it is reasonable
  to consider how this capability might be more simply accessed in a future
  version of XForms.
  
  [1] http://lists.w3.org/Archives/Public/public-forms/2007Jul/0078.html
  
  Thank you,
  John Boyer
  
  > 
  > All,
  > 
  > I have a doubt about the meaning of "empty" in the wording "required but
  > empty" (which appears in 11.2.3 and 4.3.5).
  > 
  > It seems that "empty" could either mean:
  > 
  > 1. A zero-length string (clear technical interpretation)
  > 2. A string empty as per #1 above, or a string with only white-space
  >      (human-friendly interpretation)
  > 
  > Imagine a user entering by error a space in an input field. Visually,
  > with most agents (typically web browsers), you can't tell whether the
  > field is empty according to #1 above, or contains white space. So to the
  > user, the field is "empty".
  > 
  > But if the XForms implementation implements #1, then this visually empty
  > field will be considered non-empty, and pass submission even if required.
  > 
  > This would favor an interpretation of "empty" where not only strictly
  > empty strings are "empty", but also strings containing only white space.
  > 
  > At the very least, the spec should say whether it means #1, #2, or
  > implementation-dependent.
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

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

PROBLEM ID: 163

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

NOTES:

  We add examples for: replace all, replace instance, replace none, replace text,
  xforms-submit-done, xforms-submit-error, xforms-submit, xforms-submit-serialize,
  dynamic URL in the resource section, and file load/save.

ORIGINAL MESSAGE:

  From: "Steve K Speicher" <sspeiche@us.ibm.com>
  
  
  LC comment on http://www.w3.org/TR/2007/WD-xforms11-20070222
  
  2) The Submission module is sufficiently getting more complex but found
  very few examples, I'd recommend adding  a few.
  
  Thanks,
  Steve Speicher
  IBM SWG, Software Standards
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Hi Steve,
  
  We will add submission examples to the spec.
  
  Regards,
  
  Nick Van den Bleeken
  > 
  > LC comment on http://www.w3.org/TR/2007/WD-xforms11-20070222
  > 
  > 2) The Submission module is sufficiently getting more complex but found
  > very few examples, I'd recommend adding  a few.
  > 
  > Thanks,
  > Steve Speicher
  > IBM SWG, Software Standards
  > 
  > 

12.5 [LC] 11.9 Submission Options

PROBLEM ID: 81

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

NOTES:

  The verb element/attribute pair was eliminated in favor of expanding on the
  'method'.  Since method is required to specify, there is no longer confusion
  about the default verb (by which we meant submission protocol operation, which
  under the http protocol is in fact called the method).
  
  The ability to control the "verb" now rests with the 'method', so in the table
  in 11.9 there is no longer an ambiguity about how the http method/protocol
  verb/protocol operation is obtained.  Please see the newly titled column
  "Submission Protocol Operation" and in particular the value for the row for
  "Any
  other NCName".

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#submit-options
  
  Presumably for each entry there is a corresponding default verb. Why
  not add it as a column to the table.
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The verb element/attribute pair was eliminated in favor of expanding on the
  'method'.  Since method is required to specify, there is no longer confusion
  about the default verb (by which we meant submission protocol operation, which
  under the http protocol is in fact called the method).
  
  The ability to control the "verb" now rests with the 'method', so in the table
  in 11.9 there is no longer an ambiguity about how the http method/protocol
  verb/protocol operation is obtained.  Please see the newly titled column
  "Submission Protocol Operation" and in particular the value for the row for "Any
  other NCName".
  
  We believe this solution satisfies the intent of your feedback in this last call
  issue.  Please see the editor's draft of XForms 1.1 available from the Forms WG
  home page and let us know if you have any further concerns about this issue.
  
  Thank you,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#submit-options
  > 
  > Presumably for each entry there is a corresponding default verb. Why
  > not add it as a column to the table.
  > 
  > 

12.6 [LC1.1] 11.8 The header Element

PROBLEM ID: 4

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

NOTES:

  We will relax the order.
  This is modestly substantive in that it changes the schema, but we do not expect
  objection since it relaxes the order of required child elements to ease
  authoring.  Since all child elements were required to implement, no
  implementation experience currently garnered could be invalidated by this
  change.

ORIGINAL MESSAGE:

  From: "Steve K Speicher" <sspeiche@us.ibm.com>
  
  
  LC comment on
  http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-header
  
  Section states: "The submission element can contain zero or more header
  child elements, which must appear immediately after the optional resource
  and verb elements."
  
  What happens when this occurs:
     <submission>
       <resource>...</resource>
       <header>...</header>
       <verb>...</verb>
       <header>...</header>
     </submission>
  
  Should this dispatch some fatal error?
  Should the <verb> be ignorred?
  Should the first <header> be ignorred?
  
  Why is this order important?  I can possibly see how resource and verb may
  conflict but not sure about header.
  
  This comment also indirectly applies to 11.6 <resource>, which states
  "first child of submission" and 11.7.2 verb element, which says
  "immediately after optional resource element".  As far as handling of
  these items if out of order.
  
  Thanks,
  Steve Speicher
  IBM SWG, Software Standards
  
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Hi Steve,
  
  We accepted your comments and we are going to relax the order of the elements.
  
  Regards,
  
  Nick Van den Bleeken
  > 
  > LC comment on
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-header
  > 
  > Section states: "The submission element can contain zero or more header
  > child elements, which must appear immediately after the optional resource
  > and verb elements."
  > 
  > What happens when this occurs:
  >    <submission>
  >      <resource>...</resource>
  >      <header>...</header>
  >      <verb>...</verb>
  >      <header>...</header>
  >    </submission>
  > 
  > Should this dispatch some fatal error?
  > Should the <verb> be ignorred?
  > Should the first <header> be ignorred?
  > 
  > Why is this order important?  I can possibly see how resource and verb may
  > conflict but not sure about header.
  > 
  > This comment also indirectly applies to 11.6 <resource>, which states
  > "first child of submission" and 11.7.2 verb element, which says
  > "immediately after optional resource element".  As far as handling of
  > these items if out of order.
  > 
  > Thanks,
  > Steve Speicher
  > IBM SWG, Software Standards
  > 
  > 
  > 

REPLY 2:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Aaron,
  
  You are right. We will update the spec accordingly. 
  
  Many thanks.
  
  Nick Van den Bleeken
  For the Forms WG
  
  > 
  > 
  > I know that this is a nit, but its been noticed by a couple of us on the
  > Mozilla project already so I might as well mention it.
  > 
  > In section 11.6 it says, "If the submission does not have a resource
  > element as its first child, then the submission URI is obtained from the
  > resource attribute or the action attribute."
  > 
  > I assume that this means that if submission does not have a resource
  > element as its first child ELEMENT, then the other rules apply.  The first
  > child node will quite often be a text node if submission and resource are
  > on separate lines as they will most likely be in the real world.  So
  > perhaps this line should be changed to reflect the element aspect.
  > 
  > --Aaron
  > IBM Corporation
  > Internal Zip: 9022D016
  > 11501 Burnet Road
  > Austin, TX 78758
  > (512)838-9948
  > inet: aaronr@us.ibm.com
  >    _
  >   (} @
  >   |=     Volleyball Rules!!!
  > /\
  > 
  > 

12.7 [LC] 11.7 Submission verb Attribute and Element

PROBLEM ID: 78

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

NOTES:

  The substantive change was the change of name of the 'verb' element to 'method'.
   As explained in two other LC comments, and also evident here, the name 'verb'
  was confusing and we were unable to find a current normative reference for that
  name, so the same features were renamed 'method'. No objection is expected due
  to the increase of clarity and because the name change does not invalidate any
  prior experience implementing the feature under the old name.
  
  Detailed notes:
  The verb elem/attr pair were eliminated.
  The method element was added as a way to provide an XPath expr in lieu of the
  literal value in the method attr, which is a pre-existing literal-valued attr.
  
  The method element also allows literal expression, which may still be seen as
  'overkill' but it was done for consistency, i.e. in other places in XForms
  literal content can be provided in places where the value attr can also appear.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#submit-verb
  
  "The submission element must allow a new optional attribute named verb of  
  type string."
  
  Must allow?
  
  Anyway, we now have the following possibilities:
  
        <submit verb="PUT"/>
        <submit><verb value="'PUT'"/></submit>
        <submit><verb>PUT</verb></submit>
  
  Isn't this overkill?
  
  Proposal:
  	  Since it is entirely new, use @verb as a value attribute
  	      <submit verb="../method/verb"/>
  	  Drop the verb child element.
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  We agree that there are more possibilities than there should be.
  
  However, the verb elem/attr pair were eliminated.  Instead, we now have he
  method element to provide an XPath expr in lieu of the literal value in the
  method attr, which is a pre-existing literal-valued method attribute.
  
  The method element also allows literal expression, which may still be seen as
  'overkill' but it was done for consistency, i.e. in other places in XForms
  literal content can be provided in places where the value attr can also appear.
  
  Please see the editor's draft of XForms 1.1 available from the Forms WG home
  page and let us know if you have any further concerns about this issue.
  
  Thank you,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#submit-verb
  > 
  > "The submission element must allow a new optional attribute named verb of  
  > type string."
  > 
  > Must allow?
  > 
  > Anyway, we now have the following possibilities:
  > 
  >       <submit verb="PUT"/>
  >       <submit><verb value="'PUT'"/></submit>
  >       <submit><verb>PUT</verb></submit>
  > 
  > Isn't this overkill?
  > 
  > Proposal:
  > 	  Since it is entirely new, use @verb as a value attribute
  > 	      <submit verb="../method/verb"/>
  > 	  Drop the verb child element.
  > 
  > 
  > 

12.8 1.1 resource element comment

PROBLEM ID: 54

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

ORIGINAL MESSAGE:

  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  
  
  I know that this is a nit, but its been noticed by a couple of us on the
  Mozilla project already so I might as well mention it.
  
  In section 11.6 it says, "If the submission does not have a resource
  element as its first child, then the submission URI is obtained from the
  resource attribute or the action attribute."
  
  I assume that this means that if submission does not have a resource
  element as its first child ELEMENT, then the other rules apply.  The first
  child node will quite often be a text node if submission and resource are
  on separate lines as they will most likely be in the real world.  So
  perhaps this line should be changed to reflect the element aspect.
  
  --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: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Aaron,
  
  You are right. We will update the spec accordingly. 
  
  Many thanks.
  
  Nick Van den Bleeken
  For the Forms WG
  
  > 
  > 
  > I know that this is a nit, but its been noticed by a couple of us on the
  > Mozilla project already so I might as well mention it.
  > 
  > In section 11.6 it says, "If the submission does not have a resource
  > element as its first child, then the submission URI is obtained from the
  > resource attribute or the action attribute."
  > 
  > I assume that this means that if submission does not have a resource
  > element as its first child ELEMENT, then the other rules apply.  The first
  > child node will quite often be a text node if submission and resource are
  > on separate lines as they will most likely be in the real world.  So
  > perhaps this line should be changed to reflect the element aspect.
  > 
  > --Aaron
  > IBM Corporation
  > Internal Zip: 9022D016
  > 11501 Burnet Road
  > Austin, TX 78758
  > (512)838-9948
  > inet: aaronr@us.ibm.com
  >    _
  >   (} @
  >   |=     Volleyball Rules!!!
  > /\
  > 
  > 

12.9 Re: XForms 1.1: Submit event (11.2) - @serialize

PROBLEM ID: 1

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

NOTES:

  We accepted the new defaults for relevant and validate; we changed the XForms
  submit event default processing.
  This is modestly substantive in that it changes behavior, but we do not expect
  objection since it changes defaults to the most sensible values.  Since all
  default and non-default cases were required to implement, no implementation
  experience currently garnered could be invalidated by this change.

ORIGINAL MESSAGE:

  From: "Mark Birbeck" <mark.birbeck@x-port.net>
  
  
  On the call yesterday, John suggested that one way to achieve the
  use-case I would like (of allowing a submission that does not send any
  instance data to not require validation) could be achieved by making
  the @relevant and @validate attributes *default* to the value in
  @serialize. I think this is a neat solution, and gives the author
  flexibility.
  
  So, proposed wording to go section 11.1, would be:
  
  --- STARTS ---
  
  validate
  
       Optional boolean attribute that indicates whether or not the data
  validation checks of the submission are performed. The default value
  is the value of serialize, if present, or "true", otherwise.
  
  relevant
  
       Optional boolean attribute that indicates whether or not the
  relevance pruning of the submission is performed. The default value is
  the value of serialize, if present, or "true", otherwise.
  
  serialize
  
       Optional boolean attribute with default "true" that indicates
  whether or not the instance data is serialized as part of the
  submission. This can be useful for requests that either require no
  data or that have the data already gathered in the URI. Note that that
  setting serialize to false will also have the effect of preventing
  relevance pruning and validation. The author is free to override this
  by setting relevant and/or validate to "true".
  
  --- ENDS ---
  
  On 14/02/07, Mark Birbeck <mark.birbeck@x-port.net> wrote:
  > The @serialize attribute seems to be a useful way of doing this:
  >
  >   <xf:submission
  >     ref="/IHaveNoDataToSendIJustWantToUseSubmission"
  >     method="get" action="..."
  >   />
  >
  > i.e.:
  >
  >   <xf:submission
  >     serialize="false"
  >     method="get" action="..."
  >   />
  >
  > However, because @serialize is not referred to until step 7 in 11.2,
  > the processor will already have gone through relevance filtering and
  > validity testing. Also, if there were no node to serialise from, step
  > 2 would actually fail, despite the fact that the author actually
  > doesn't want to serialise anything.
  >
  > Is it possible we can harmonise the two more, so that serialize can be
  > used to indicate that you don't want to send any data, but you do want
  > to use the whole submission infrastructure. This is particularly
  > common when using a REST design, since a GET on a URL is all you need
  > to do to get a resource. Likewise picking up RSS feeds.
  >
  > Perhaps a modification to step 2 along these lines is all that's needed:
  >
  >   A node from the instance data is selected, based on attributes on
  >   the submission element. <add>If the value of serialize is false,
  >   processing continues at step 4, with no data selected.</add> If the
  >   attributes of submission select an empty nodeset...
  >
  > 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.
  >
  
  
  -- 
     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: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thanks Mark. We accepted and made this change at the FtF 2007-06-13.
  
  Best wishes,
  
  Steven Pemberton
  
  > On the call yesterday, John suggested that one way to achieve the
  > use-case I would like (of allowing a submission that does not send any
  > instance data to not require validation) could be achieved by making
  > the @relevant and @validate attributes *default* to the value in
  > @serialize. I think this is a neat solution, and gives the author
  > flexibility.
  > 
  > So, proposed wording to go section 11.1, would be:
  > 
  > --- STARTS ---
  > 
  > validate
  > 
  >      Optional boolean attribute that indicates whether or not the data
  > validation checks of the submission are performed. The default value
  > is the value of serialize, if present, or "true", otherwise.
  > 
  > relevant
  > 
  >      Optional boolean attribute that indicates whether or not the
  > relevance pruning of the submission is performed. The default value is
  > the value of serialize, if present, or "true", otherwise.
  > 
  > serialize
  > 
  >      Optional boolean attribute with default "true" that indicates
  > whether or not the instance data is serialized as part of the
  > submission. This can be useful for requests that either require no
  > data or that have the data already gathered in the URI. Note that that
  > setting serialize to false will also have the effect of preventing
  > relevance pruning and validation. The author is free to override this
  > by setting relevant and/or validate to "true".
  > 
  > --- ENDS ---
  > 
  > On 14/02/07, Mark Birbeck <mark.birbeck@x-port.net> wrote:
  >> The @serialize attribute seems to be a useful way of doing this:
  >>
  >>   <xf:submission
  >>     ref="/IHaveNoDataToSendIJustWantToUseSubmission"
  >>     method="get" action="..."
  >>   />
  >>
  >> i.e.:
  >>
  >>   <xf:submission
  >>     serialize="false"
  >>     method="get" action="..."
  >>   />
  >>
  >> However, because @serialize is not referred to until step 7 in 11.2,
  >> the processor will already have gone through relevance filtering and
  >> validity testing. Also, if there were no node to serialise from, step
  >> 2 would actually fail, despite the fact that the author actually
  >> doesn't want to serialise anything.
  >>
  >> Is it possible we can harmonise the two more, so that serialize can be
  >> used to indicate that you don't want to send any data, but you do want
  >> to use the whole submission infrastructure. This is particularly
  >> common when using a REST design, since a GET on a URL is all you need
  >> to do to get a resource. Likewise picking up RSS feeds.
  >>
  >> Perhaps a modification to step 2 along these lines is all that's needed:
  >>
  >>   A node from the instance data is selected, based on attributes on
  >>   the submission element. <add>If the value of serialize is false,
  >>   processing continues at step 4, with no data selected.</add> If the
  >>   attributes of submission select an empty nodeset...
  >>
  >> 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.
  >>
  > 
  > 
  > -- 
  >    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 2:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The verb element/attribute pair was eliminated in favor of expanding on the
  'method'.  Since method is required to specify, there is no longer confusion
  about the default verb (by which we meant submission protocol operation, which
  under the http protocol is in fact called the method).
  
  The ability to control the "verb" now rests with the 'method', so in the table
  in 11.9 there is no longer an ambiguity about how the http method/protocol
  verb/protocol operation is obtained.  Please see the newly titled column
  "Submission Protocol Operation" and in particular the value for the row for "Any
  other NCName".
  
  We believe this solution satisfies the intent of your feedback in this last call
  issue.  Please see the editor's draft of XForms 1.1 available from the Forms WG
  home page and let us know if you have any further concerns about this issue.
  
  Thank you,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#submit-options
  > 
  > Presumably for each entry there is a corresponding default verb. Why
  > not add it as a column to the table.
  > 
  > 

12.10 last call comments for section 11

PROBLEM ID: 46

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

NOTES:

  Most of the changes were editorial, but in one case we changed the name of an
  element from verb to method because we could find no current normative
  references for the prior name ('verb') and it was that name which caused the
  confusion.  We expect no objections since the name change simply clarifies what
  is going on and could not invalidate implementation experience garnered thus far
  with implementing the feature under the old name.

ORIGINAL MESSAGE:

  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  
  The last of my last call comments.  Covers section 11.
  
  1) 11.1 - I'd reword the last sentence of the description for @mode,
  especially the last section of the sentence after the ','.
  2) 11.1 - What are the valid possible values for @verb?  Not mentioned in
  the schema.  What is a 'submission protocol verb'?  Do you mean that it
  overrides @method?
  3) 11.1 - I'd suggest that the end of section 11.1 (before 11.2) is a good
  place to list the 'worker elements' that can appear as children since this
  information can't be found in the schema.
  4) 11.2 - extraneous ')' in the second sentence.
  5) 11.2 - #2 - So even if @relevant="false", we can't bind xf:submission to
  a non-relevant node?  That seems counter-intuitive.
  6) 11.2 - second bullet after #8 - Missed capitalizing 'if' which starts
  the sentence, "If the parse fails, then submission processing concludes..."
  7) 11.7.2 - the first sentence doesn't make sense.  Perhaps it should read,
  "The submission element can optionally <contain> a child element named
  verb..."
  8) 11.8 - what about header information that might be determined also by
  other things?  Like charset?  Does that also override?  What if header
  information is duplicated?
  9) 11.8.1 - also other places where the new worker elements live - what if
  @value is an invalid xpath expression?  No xforms-compute-exception?  Or
  any other kind of error?
  10) 11.9 - the sentence right before the serialization table - the word
  'attribute' is duplicated.
  11) 11.12 - third bullet - extraneous 'as' in "Element nodes selected for
  includesion are as encoded as ..."
  12) 11.19.3 - fifth bullet - should probably be 'changed', not 'change' in
  "...header is change to text/xml"
  
  Good luck finishing up the 1.1 work!
  --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: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  The working group has accepted and implemented fixes for these last call
  comments.  Please see the editor's draft available from the working group home
  page.
  
  Further specific comments are placed inline below as needed.
  
  Thanks,
  John Boyer
  
  > 
  > The last of my last call comments.  Covers section 11.
  > 
  > 1) 11.1 - I'd reword the last sentence of the description for @mode,
  > especially the last section of the sentence after the ','.
  > 2) 11.1 - What are the valid possible values for @verb?  Not mentioned in
  > the schema.  What is a 'submission protocol verb'?  Do you mean that it
  > overrides @method?
  
  Renamed verb to method to clarify that this is indeed true.
  
  > 3) 11.1 - I'd suggest that the end of section 11.1 (before 11.2) is a good
  > place to list the 'worker elements' that can appear as children since this
  > information can't be found in the schema.
  
  done, although the schema will also be updated.
  
  > 4) 11.2 - extraneous ')' in the second sentence.
  > 5) 11.2 - #2 - So even if @relevant="false", we can't bind xf:submission to
  > a non-relevant node?  That seems counter-intuitive.
  
  Fixed.
  
  > 6) 11.2 - second bullet after #8 - Missed capitalizing 'if' which starts
  > the sentence, "If the parse fails, then submission processing concludes..."
  > 7) 11.7.2 - the first sentence doesn't make sense.  Perhaps it should read,
  > "The submission element can optionally <contain> a child element named
  > verb..."
  > 8) 11.8 - what about header information that might be determined also by
  > other things?  Like charset?  Does that also override?  What if header
  > information is duplicated?
  
  The next sentence after the one to which you refer explains that the headers are
  appended to those available by other means i.e. the underlying user agent.
  The one "override" to which we refer is an instance where *XForms* is overriding
  a header that *XForms* generates via another means. Otherwise, there are no
  overrides.  Basically, the headers are not processed by XForms, so the
  interaction of the headers generated by XForms with those obtained by other
  means is not under the control of XForms.
  
  > 9) 11.8.1 - also other places where the new worker elements live - what if
  > @value is an invalid xpath expression?  No xforms-compute-exception?  Or
  > any other kind of error?
  
  Throughout the spec (i.e. not just in submissions), the failure to evaluate an
  XPath in a value attribute results in just using the empty string.  Processing
  is not halted with an exception (and no appropriate exception is currently
  defined for cases like this).
  
  > 10) 11.9 - the sentence right before the serialization table - the word
  > 'attribute' is duplicated.
  > 11) 11.12 - third bullet - extraneous 'as' in "Element nodes selected for
  > includesion are as encoded as ..."
  > 12) 11.19.3 - fifth bullet - should probably be 'changed', not 'change' in
  > "...header is change to text/xml"
  > 
  > Good luck finishing up the 1.1 work!
  > --Aaron
  > IBM Corporation
  > Internal Zip: 9022D016
  > 11501 Burnet Road
  > Austin, TX 78758
  > (512)838-9948
  > inet: aaronr@us.ibm.com
  >    _
  >   (} @
  >   |=     Volleyball Rules!!!
  > /\
  > 
  > 

12.11 [LC] 11.8 The header Element

PROBLEM ID: 80

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

NOTES:

  The main reason is that the WG felt that XPath-based name and value attributes
  made it too difficult for the case of specifying a literal, which is easier to
  understand when you recognize that the nodeset attribute is optional.
  
  Basically, the header element was created *and then* nodeset was added to
  simplify getting a large block of headers from instance data.
  
  So the question might then become, why can't we add name and value as literal
  attributes at least.  Two reasons.  First, this variant is not useful when
  nodeset is used.  Second, when there is no nodeset, it does indeed seem less
  verbose to specify a header with attributes.  The problem we encountered there
  was that the value attribute would then be a literal string, which is
  inconsistent with its datatype of XPathExpr everywhere else in XForms.  And if
  we make it an XPath, then again we would be in the trap of authors having
  frustration when they forget to put the extra quotes needed to express a string
  literal in an XPath.  So, in this case, the WG felt it was best to have only
  the
  child elements name and value, both of which offer a literal content version
  and
  a value attribute for specifying an XPath.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#submit-header
  
  This seems over-engineered. Why not instead of
  
        <header nodeset="...">
  	     <name value=".../>
  	     <value value="..."/>
        </header
  
  use the simpler:
  
       <header nodeset="..." name="..." value="..."/>
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  Thank you very much for considering this issue.  In this case, the working group
  did not implement a change based on the feedback, and I will now endeavor to
  explain why.
  
  The main reason is that the WG felt that XPath-based name and value attributes
  made it too difficult for the case of specifying a literal, which is easier to
  understand when you recognize that the nodeset attribute is optional.
  
  Basically, the header element was created *and then* nodeset was added to
  simplify the specification of multiple headers from instance data.
  
  So the question might then become, why can't we add name and value as literal
  attributes at least.  Two reasons.  First, this variant is not useful when
  nodeset is used.  Second, when there is no nodeset, it does indeed seem less
  verbose to specify a header with attributes.  The problem we encountered there
  was that the value attribute would then be a literal string, which is
  inconsistent with its datatype of XPathExpr everywhere else in XForms.  And if
  we make it an XPath, then again we would be in the trap of authors having
  frustration when they forget to put the extra quotes needed to express a string
  literal in an XPath.  So, in this case, the WG felt it was best to have only the
  child elements name and value, both of which offer a literal content version and
  a value attribute for specifying an XPath.
  
  Please let us know if you have any further concerns about this issue.
  
  Thank you,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#submit-header
  > 
  > This seems over-engineered. Why not instead of
  > 
  >       <header nodeset="...">
  > 	     <name value=".../>
  > 	     <value value="..."/>
  >       </header
  > 
  > use the simpler:
  > 
  >      <header nodeset="..." name="..." value="..."/>
  > 
  > 
  > 

12.12 [LC] 11.6 The resource Element and Attribute

PROBLEM ID: 77

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

NOTES:

  We did not make resource into an XPath because this would be inconsistent with
  how resource is used on instance and on load.  Uniformly, resource is an
  xsd:anyURI.
  
  It wouldn't be overkill if @action were deprecated, which is perhaps what was
  not clear enough.  I think we should modify/accept this by making it clearer
  that we  want to deprecate @action.
  
  The reason above for deprecating action is so that we consistently use the name
  resource, but there is a second reason too.  The name 'action' for the
  attribute
  is constantly confusing in explanations of submission because one must
  distinguish between action, the URI, and action, the handler of
  xforms-submit-done.  By deprecating @action, there would no longer be a name
  conflict.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#submit-resource
  
  "The URI to be used by the submission can be specified with either the
  value attribute or the string content of the resource element."
  
  So we now have the following equivalent possibilities:
  
        <submit action="http://examples.org/search"/>
        <submit resource="http://examples.org/search"/>
        <submit><resource value="'http://examples.org/search'"/></submit>
        <submit><resource>http://examples.org/search</resource></submit>
  
  Isn't this overkill?
  
  Proposal:
  	  Keep @action for the literal case
  	  Use @resource as a value attribute
  	      <submit resource="concat('http://', site, '/', command)"/>
  	  Drop the resource child.
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The Forms WG agrees that it is confusing and 'overkill' to have both an action
  and a resource attribute.
  
  The resolution in this case was to clearly mark the action attribute as
  deprecated (supported, but not the preferred attribute to use anymore). There
  are two reasons for this.  First, the term 'action' in XForms is already used to
  describe event handlers, so discussions of submission have been confusing
  because one can also have actions that handle various submission events. 
  Switching to a resource attribute clears up that ambiguity.  Second, the WG
  decided to consistently use the attribute name 'resource' as it is used
  elsewhere in XForms (the load action and the instance element).
  
  Regarding the suggestion to let resource be an XPath expression since we already
  have action for the literal case, the above resolution clarifies that the intent
  is to have resource be used in lieu of action.  For consistency with the use of
  the resource attribute in the load action and the instance element, the datatype
  must be an xsd:anyURI.  Also, for consistency with how XPath expressions are
  provided to other attributes in XForms 1.1, the resource child element is
  provided.
  
  Please see the editor's draft of the specification available from the Forms WG
  home page and let us know if you have any further concerns about this issue.
  
  Thank you,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#submit-resource
  > 
  > "The URI to be used by the submission can be specified with either the
  > value attribute or the string content of the resource element."
  > 
  > So we now have the following equivalent possibilities:
  > 
  >       <submit action="http://examples.org/search"/>
  >       <submit resource="http://examples.org/search"/>
  >       <submit><resource value="'http://examples.org/search'"/></submit>
  >       <submit><resource>http://examples.org/search</resource></submit>
  > 
  > Isn't this overkill?
  > 
  > Proposal:
  > 	  Keep @action for the literal case
  > 	  Use @resource as a value attribute
  > 	      <submit resource="concat('http://', site, '/', command)"/>
  > 	  Drop the resource child.
  > 
  > 
  > 

12.13 [LC: editorial] 11.2 The xforms-submit Event

PROBLEM ID: 79

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/#submit-evt-submit
  
  Contains the sentence "action processing is blocked within in the
  default processing" which has "within in"
  

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/#submit-evt-submit
  > 
  > Contains the sentence "action processing is blocked within in the
  > default processing" which has "within in"
  > 
  > 

13. Types

13.1 [XForms 1.1] i18n comment: Restriction of international mail addresses unclear

PROBLEM ID: 10

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 6
  At http://www.w3.org/International/reviews/0704-xforms11/
  Editorial/substantive: S
  Location in reviewed document:
  5.2.5
  Restriction of international mail addresses unclear
  
  Comment:
  
    Internationalized email addresses are not restricted by XForms beyond the  
  definition in the RFC.
  
  Please clarify whether it is possible to use internationalized email or  
  not. We feel that it would be important that it is possible.
  
  
  
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thank you for this comment. It has sparked an animated discussion about whether
  the lexical values or the ascii values for international email addresses should
  be stored in the XForms instances. We have come to the conclusion that it should
  be the lexical values, rather than the regular expression used in 5.2.5 of the
  XForms 1.1 spec.
  
  However, we would value your advice on the correct regular expression for an
  international email address. Would you be willing to help us with that?
  
  Many thanks.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  
  > Comment from the i18n review of:
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > 
  > Comment 6
  > At http://www.w3.org/International/reviews/0704-xforms11/
  > Editorial/substantive: S
  > Location in reviewed document:
  > 5.2.5
  > Restriction of international mail addresses unclear
  > 
  > Comment:
  > 
  >   Internationalized email addresses are not restricted by XForms beyond the  
  > definition in the RFC.
  > 
  > Please clarify whether it is possible to use internationalized email or  
  > not. We feel that it would be important that it is possible.
  > 
  > 
  > 
  > 
  > 

REPLY 2:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  We have decided that we will defer the issue about international mail addresses
  to a future XForms version, where i18mail can be defined and keep current
  pattern definition of XForms email. Due to the fact that we are able to define
  the schema type of an international mail addresses today.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > Comment from the i18n review of:
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > 
  > Comment 6
  > At http://www.w3.org/International/reviews/0704-xforms11/
  > Editorial/substantive: S
  > Location in reviewed document:
  > 5.2.5
  > Restriction of international mail addresses unclear
  > 
  > Comment:
  > 
  >   Internationalized email addresses are not restricted by XForms beyond the  
  > definition in the RFC.
  > 
  > Please clarify whether it is possible to use internationalized email or  
  > not. We feel that it would be important that it is possible.
  > 
  > 
  > 
  > 
  > 

13.2 Section 5.1

PROBLEM ID: 136

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

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
  
      A. It seems odd that xs:double is not included in the core subset
      since it's the only numeric data type supported by XPath 1.0
  
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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:
  ----------------------------------------------------------------------------
  
  
  Thanks for the comment. In fact we have removed the information about the
  smaller conformance profile since it is not relevant to this specification.
  
  XForms Basic (a different specification) doesn't include double at present, but
  we anticipate that it will be added to a future version.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  >     A. It seems odd that xs:double is not included in the core subset
  >     since it's the only numeric data type supported by XPath 1.0
  
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thanks for the comment. In fact we have removed the information about the
  smaller conformance profile since it is not relevant to this specification.
  
  XForms Basic (a different specification) doesn't include double at present, but
  we anticipate that it will be added to a future version.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  >     A. It seems odd that xs:double is not included in the core subset
  >     since it's the only numeric data type supported by XPath 1.0

13.3 Section 5.2.7

PROBLEM ID: 138

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

NOTES:

  Essentially duplicate of issue types/22.
  
  We are rewriting the paragrqaph to take away the confusion.

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
  
      C. It's not clear which of these data types allow empty content and
      which don't. What is meant by "the indicated datatypes"? Also,
      there should be a more formal definition of these types, for
      example they could be defined either as a union of the base type
      with a zero-length string, or as a list of zero-or-one items of the
      base type. Such a definition affects the semantics of XPath
      expressions applied to values of these types. We do not understand
      paragraph 2, which appears to contradict paragraph 1.
  
  

FOLLOWUP 1:

  From: "Michael Kay" <mike@saxonica.com>
  
  Thanks.
  
  From the point of view of typed XPath processing, a list of length 0-or-1 is
  probably preferable to a union-with-"". For example, sum() in the list case
  would ignore empty values, whereas in the union case it would give a type
  error because an empty value is treated as a string. Similarly x[@a > 3]
  would effectively ignore empty values of @a if treated as a list, but give a
  type error if treated as a union.
  
  From a validation perspective, of course, there is no difference.
  
  Michael Kay
   
  
  > -----Original Message-----
  > From: Steven Pemberton [mailto:xforms-issues@mn.aptest.com] 
  > Sent: 14 June 2007 21:14
  > To: mike@saxonica.com
  > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
  > Subject: Re: Section 5.2.7 (PR#138)
  > 
  > Thanks for the comment. In fact the introductory paragraph 
  > confused even us when we reread it :-)
  > 
  > We are rewriting this paragraph to make it clear that all 
  > datatypes here allow empty content. They will indeed be 
  > defined as unions in the Schema for XForms 1.1.
  > 
  > Best wishes,
  > 
  > Steven Pemberton
  > For the Forms WG
  > 
  > >     C. It's not clear which of these data types allow empty 
  > content and
  > >     which don't. What is meant by "the indicated datatypes"? Also,
  > >     there should be a more formal definition of these types, for
  > >     example they could be defined either as a union of the base type
  > >     with a zero-length string, or as a list of zero-or-one 
  > items of the
  > >     base type. Such a definition affects the semantics of XPath
  > >     expressions applied to values of these types. We do not 
  > understand
  > >     paragraph 2, which appears to contradict paragraph 1.
  > > 
  > > 
  > > 
  

FOLLOWUP 2:

  From: w3c-xml-query-wg-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:
  ----------------------------------------------------------------------------
  
  
  Thanks for the comment. In fact the introductory paragraph confused even us when
  we reread it :-)
  
  We are rewriting this paragraph to make it clear that all datatypes here allow
  empty content. They will indeed be defined as unions in the Schema for XForms
  1.1.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  >     C. It's not clear which of these data types allow empty content and
  >     which don't. What is meant by "the indicated datatypes"? Also,
  >     there should be a more formal definition of these types, for
  >     example they could be defined either as a union of the base type
  >     with a zero-length string, or as a list of zero-or-one items of the
  >     base type. Such a definition affects the semantics of XPath
  >     expressions applied to values of these types. We do not understand
  >     paragraph 2, which appears to contradict paragraph 1.
  > 
  > 
  > 
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thanks for the comment. In fact the introductory paragraph confused even us when
  we reread it :-)
  
  We are rewriting this paragraph to make it clear that all datatypes here allow
  empty content. They will indeed be defined as unions in the Schema for XForms
  1.1.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  >     C. It's not clear which of these data types allow empty content and
  >     which don't. What is meant by "the indicated datatypes"? Also,
  >     there should be a more formal definition of these types, for
  >     example they could be defined either as a union of the base type
  >     with a zero-length string, or as a list of zero-or-one items of the
  >     base type. Such a definition affects the semantics of XPath
  >     expressions applied to values of these types. We do not understand
  >     paragraph 2, which appears to contradict paragraph 1.
  > 
  > 
  > 

13.4 [XForms 1.1] i18n comment: Lexical space for XForms data types missing

PROBLEM ID: 6

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

NOTES:

  Prior notes were incorrect.
  Section 8.1.1 is using the terms correctly.
  Section 5 has to mention that lex space is what goes into and comes out of the
  data, and that the datatype descriptions in section 5 are generally lex space
  descriptions.

ORIGINAL MESSAGE:

  From: fsasaki@w3.org
  
  
  Comment from the i18n review of:
  http://www.w3.org/TR/2007/WD-xforms11-20070222/
  
  Comment 1
  At http://www.w3.org/International/reviews/0704-xforms11/
  Editorial/substantive: S
  Location in reviewed document:
  5.2
  Lexical space for XForms data types missing
  
  Comment:
  
  The description of the XForms data types does not in every case provide  
  information about the lexical space(s), but only about the value spaces.  
  Please provide a statement describing the relation.
  
  
  
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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:
  ----------------------------------------------------------------------------
  
  
  Thanks for the comment. In fact we have removed the information about the
  smaller conformance profile since it is not relevant to this specification.
  
  XForms Basic (a different specification) doesn't include double at present, but
  we anticipate that it will be added to a future version.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  >     A. It seems odd that xs:double is not included in the core subset
  >     since it's the only numeric data type supported by XPath 1.0
  
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  We agree. Although there is some text in section 8 on controls, suggesting the
  difference between the two, we agree that it should be made clear in section 5
  on datatypes as well.
  
  Thanks you for the comment.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  > Comment from the i18n review of:
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > 
  > Comment 1
  > At http://www.w3.org/International/reviews/0704-xforms11/
  > Editorial/substantive: S
  > Location in reviewed document:
  > 5.2
  > Lexical space for XForms data types missing
  > 
  > Comment:
  > 
  > The description of the XForms data types does not in every case provide  
  > information about the lexical space(s), but only about the value spaces.  
  > Please provide a statement describing the relation.

REPLY 2:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Thanks for the comment. In fact we have removed the information about the
  smaller conformance profile since it is not relevant to this specification.
  
  XForms Basic (a different specification) doesn't include double at present, but
  we anticipate that it will be added to a future version.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  >     A. It seems odd that xs:double is not included in the core subset
  >     since it's the only numeric data type supported by XPath 1.0

13.5 XML Core WG review of XForms 1.1

PROBLEM ID: 48

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

ORIGINAL MESSAGE:

  From: "John Cowan" <cowan@ccil.org>
  
  
  The XML Core WG (for which I am speaking officially) has found the
  following six issues with the Last Call draft of XForms 1.1:
  
  1) XForms inherits the definition of "id" from the language in which it
  is embedded; as such, it cannot be readily embedded in a language where
  the ID attribute is "xml:id".  Either should be allowed.
  
  2) There is a normative reference to XForms 1.0 that seems unnecessary,
  as XForms 1.1 is self-contained.
  
  3) The types xforms:dayTimeDuration and yearMonthDuration should be
  moved to the list of datatypes that allow empty content in 5.2.7,
  and their places should be occupied by the types xs:dayTimeDuration
  and xs:yearMonthDuration.  These types are in the XML Schema namespace,
  but are defined by the XQuery 1.0/XSLT 2.0 data model.
  
  4) xs: seems to be preferred to xsd: as the prefix for the XML Schema
  namespace; xsd: suggests the XML Schema Datatypes namespace.
  
  5) The XForms-specific procedures should be harmonized with the XPath
  2.0 function library where possible.
  
  6) XForms 1.1 refers to the standard ISO/IEC 7812-1 normatively in order
  to define the credit card checksum algorithm.  This standard is available
  only for money, and we think the algorithm should be restated in XForms 1.1
  and the reference changed to an informative one.  The algorithm itself
  is in the public domain; an adequate specification of it can be found
  at http://en.wikipedia.org/wiki/Luhn_algorithm .
  
  -- 
  Unless it was by accident that I had            John Cowan
  offended someone, I never apologized.           cowan@ccil.org
           --Quentin Crisp                         http://www.ccil.org/~cowan
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  > The XML Core WG (for which I am speaking officially) has found the
  > following six issues with the Last Call draft of XForms 1.1:
  > 
  > 1) XForms inherits the definition of "id" from the language in which it
  > is embedded; as such, it cannot be readily embedded in a language where
  > the ID attribute is "xml:id".  Either should be allowed.
  > 
  
  We added a note to Common Attributes: "Elements can be identified using any
  attribute of type ID (such as xml:id), not just the id attribute defined
  above."
  
  > 2) There is a normative reference to XForms 1.0 that seems unnecessary,
  > as XForms 1.1 is self-contained.
  > 
  
  We moved XForms 1.0 to a informative reference.
  
  > 3) The types xforms:dayTimeDuration and yearMonthDuration should be
  > moved to the list of datatypes that allow empty content in 5.2.7,
  > and their places should be occupied by the types xs:dayTimeDuration
  > and xs:yearMonthDuration.  These types are in the XML Schema namespace,
  > but are defined by the XQuery 1.0/XSLT 2.0 data model.
  > 
  
  We cannot move xforms:dayTimeDuration and xforms:yearMonthDuration to the xs:
  types from XQuery 1.0 / XSLT 2.0 because XForms 1.1 is based on XML Schema 1.0
  and XPath 1.0.
  
  > 4) xs: seems to be preferred to xsd: as the prefix for the XML Schema
  > namespace; xsd: suggests the XML Schema Datatypes namespace.
  > 
  
  We change xsd:schema and children to xs:schema and children, and add a
  definition of the xs: namespace, but leave occurrences the definition
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" and the uses on datatypes, because
  that's what XML Schema Part 0 does.  Implementors will already note that XML
  Schema requires handling of type definitions in the
  xmlns:xsd="http://www.w3.org/2001/XMLSchema-datatypes" namespace without special
  instruction from XForms.
  
  > 5) The XForms-specific procedures should be harmonized with the XPath
  > 2.0 function library where possible.
  > 
  
  We agree that XForms-specific procedures should be harmonized with XPath 2.0
  functions library where possible.
  
  > 6) XForms 1.1 refers to the standard ISO/IEC 7812-1 normatively in order
  > to define the credit card checksum algorithm.  This standard is available
  > only for money, and we think the algorithm should be restated in XForms 1.1
  > and the reference changed to an informative one.  The algorithm itself
  > is in the public domain; an adequate specification of it can be found
  > at http://en.wikipedia.org/wiki/Luhn_algorithm .
  > 
  
  We change the Luhn reference from ISO/IEC 7912-1 to expired patent "U.S. PATENT
  2,950,048 Computer for Verifying Numbers.", H.P. Luhn.  We change terminology
  from "Luhn formula" to "Luhn algorithm" to make finding the Wikipedia entry
  easy.  We retain "Luhn function" for now.
  
  > -- 
  > Unless it was by accident that I had            John Cowan
  > offended someone, I never apologized.           cowan@ccil.org
  >          --Quentin Crisp                         http://www.ccil.org/~cowan
  > 
  > 
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG

13.6 Section 5.2.3

PROBLEM ID: 137

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

NOTES:

  RESOLUTION: Stick with types defined in schema 1.0 and add new types when we
  transition to later versions of schema

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
  
      B. dayTimeDuration and yearMonthDuration are now available in the
      XML Schema namespace. We encourage you to adopt these new types.
  
  
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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 Michael,
  
  The Forms Working group resolved to change the specification to make it clearer
  that XML schema 1.0 only datatypes are supported in XForms 1.1.  XForms already
  subtracts four datatypes from that list, so it did not make as much sense for us
  to then add two datatypes not in schema 1.0 considering that is the spec we
  normatively reference.
  
  Note, however, that these types could be added to any XForm by using a schema. 
  Also, the default datatypes available without using a schema already make
  available these two kinds of durations, except they also allow empty content
  into the lexical space by default.  Hence, the exact datatype can be achieved by
  using the xforms defined datatypes in combination with the required model item
  property.
  
  We hope that this information explains why we did not adopt these datatypes for
  XForms 1.1.
  
  Thank you,
  John Boyer
  
  > 
  > 
  > 
  >     B. dayTimeDuration and yearMonthDuration are now available in the
  >     XML Schema namespace. We encourage you to adopt these new types.
  > 
  > 
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  The Forms Working group resolved to change the specification to make it clearer
  that XML schema 1.0 only datatypes are supported in XForms 1.1.  XForms already
  subtracts four datatypes from that list, so it did not make as much sense for us
  to then add two datatypes not in schema 1.0 considering that is the spec we
  normatively reference.
  
  Note, however, that these types could be added to any XForm by using a schema. 
  Also, the default datatypes available without using a schema already make
  available these two kinds of durations, except they also allow empty content
  into the lexical space by default.  Hence, the exact datatype can be achieved by
  using the xforms defined datatypes in combination with the required model item
  property.
  
  We hope that this information explains why we did not adopt these datatypes for
  XForms 1.1.
  
  Thank you,
  John Boyer
  
  > 
  > 
  > 
  >     B. dayTimeDuration and yearMonthDuration are now available in the
  >     XML Schema namespace. We encourage you to adopt these new types.
  > 
  > 
  > 
  > 

13.7 [LC] 5.2.5 xforms:email and 5.2.6 xforms:ID-card-number

PROBLEM ID: 98

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

NOTES:

  This only barely substantive because it implies a schema change, but we expect
  no objections because these two new datatypes are expected to behave
  consistently with all other xforms datatypes, which have been painstakingly
  added to allow a user to start out with an empty document that does not complain
  of validity errors on start up.  That a node must be non-empty by the end of the
  form fill experience is uniformly handled by the 'required' MIP.
  
  Note this also applies to listItem listItems dayTimeDuration and
  yearMonthDuration

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#email-type
  http://www.w3.org/TR/xforms11/#id-card-type
  
  All the other xforms: datatypes allow empty as a value. These two don't,
  and I think this is just an oversight.
  
  Steven
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The working group agrees that all XForms-defined datatypes allow empty content,
  and the specification has been amended to reflect this.  Please see the updated
  version available from the editor's draft links on the Forms WG homepage.
  
  Thanks,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#email-type
  > http://www.w3.org/TR/xforms11/#id-card-type
  > 
  > All the other xforms: datatypes allow empty as a value. These two don't,
  > and I think this is just an oversight.
  > 
  > Steven
  > 
  > 

13.8 [XForms 1.1] i18n comment: Reference to definition of data types missing

PROBLEM ID: 7

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

NOTES:

  RESOLUTION : We stick with types defined in schema 1.0 and add new types when
  we transition to later versions of schema

ORIGINAL MESSAGE:

  From: fsasaki@w3.org
  
  
  Comment from the i18n review of:
  http://www.w3.org/TR/2007/WD-xforms11-20070222/
  
  Comment 2
  At http://www.w3.org/International/reviews/0704-xforms11/
  Editorial/substantive: S
  Location in reviewed document:
  5.2.3 and 5.2.4
  Reference to definition of data types missing
  
  Comment:
  
  The data types
  dateTimeDuration
    and
  yearMonthDuration
    are described as XForms data types, but they are data types defined in the
  XQuery Data Model [http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/]
    specification. Please provide a reference to this specification from sec.  
  5.2.3 and 5.2.4. See also the
  related comment from the XML Core WG  
  [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0007.html]
  , which is basically the same.
  
  
  
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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 Michael,
  
  The Forms Working group resolved to change the specification to make it clearer
  that XML schema 1.0 only datatypes are supported in XForms 1.1.  XForms already
  subtracts four datatypes from that list, so it did not make as much sense for us
  to then add two datatypes not in schema 1.0 considering that is the spec we
  normatively reference.
  
  Note, however, that these types could be added to any XForm by using a schema. 
  Also, the default datatypes available without using a schema already make
  available these two kinds of durations, except they also allow empty content
  into the lexical space by default.  Hence, the exact datatype can be achieved by
  using the xforms defined datatypes in combination with the required model item
  property.
  
  We hope that this information explains why we did not adopt these datatypes for
  XForms 1.1.
  
  Thank you,
  John Boyer
  
  > 
  > 
  > 
  >     B. dayTimeDuration and yearMonthDuration are now available in the
  >     XML Schema namespace. We encourage you to adopt these new types.
  > 
  > 
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Felix,
  
  The working group considered this issue and decide to leave the datatype
  definitions in the XForms namespace for three reasons.  First, XForms is based
  on XML Schema 1.0, so new types will be added to a future version of XForms when
  an updated version of XML schema is adopted.  Second, datatypes in the XForms
  namespace are more convenient for form authors because they do not have to be
  namespace qualified in 'type' MIPs.  Third, the XForms versions actually are
  differeent because they also permit empty strings, which is also more convenient
  for form authoring.
  
  Generally, the latter two reasons are particularly important as they explain why
  all the xsd simple types have corresponding xforms datatypes.  XML schema has
  the mindset of validating a "full" schema instance, i.e. data that is about to
  be processed by a server-side business process.  This is a bit of a
  technological mismatch for forms, which describe the process for getting from
  "empty" schema instance to "full" schema instance.
  
  I hope you find this rationale satisfactory.
  
  Best regards,
  John Boyer
  
  > 
  > Comment from the i18n review of:
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > 
  > Comment 2
  > At http://www.w3.org/International/reviews/0704-xforms11/
  > Editorial/substantive: S
  > Location in reviewed document:
  > 5.2.3 and 5.2.4
  > Reference to definition of data types missing
  > 
  > Comment:
  > 
  > The data types
  > dateTimeDuration
  >   and
  > yearMonthDuration
  >   are described as XForms data types, but they are data types defined in the
  > XQuery Data Model [http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/]
  >   specification. Please provide a reference to this specification from sec.  
  > 5.2.3 and 5.2.4. See also the
  > related comment from the XML Core WG  
  > [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0007.html]
  > , which is basically the same.
  > 
  > 
  > 
  > 
  > 

REPLY 2:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  These have been done and can now be found in the editor's draft available from
  the working group home pages.
  
  Best regards,
  John Boyer
  
  > 
  > 
  > http://www.w3.org/TR/xforms11/#email-type
  > 
  > Please add to the "Examples of invalid xforms:email addresses"
  > 
  > 	mailto:editors@example.com
  > 
  > (and point out, maybe, that this is a valid anyURI)
  > 
  > Steven
  > 
  > 

REPLY 3:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  The Forms Working group resolved to change the specification to make it clearer
  that XML schema 1.0 only datatypes are supported in XForms 1.1.  XForms already
  subtracts four datatypes from that list, so it did not make as much sense for us
  to then add two datatypes not in schema 1.0 considering that is the spec we
  normatively reference.
  
  Note, however, that these types could be added to any XForm by using a schema. 
  Also, the default datatypes available without using a schema already make
  available these two kinds of durations, except they also allow empty content
  into the lexical space by default.  Hence, the exact datatype can be achieved by
  using the xforms defined datatypes in combination with the required model item
  property.
  
  We hope that this information explains why we did not adopt these datatypes for
  XForms 1.1.
  
  Thank you,
  John Boyer
  
  > 
  > 
  > 
  >     B. dayTimeDuration and yearMonthDuration are now available in the
  >     XML Schema namespace. We encourage you to adopt these new types.
  > 
  > 
  > 
  > 

13.9 1.0 errata section 10 (complex type validation clarification)

PROBLEM ID: 135

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

ORIGINAL MESSAGE:

  From: "Steve K Speicher" <sspeiche@us.ibm.com>
  
  
  Leigh,
  
  Thanks for the quick and thorough reply, I have responded inline.
  
  Thanks,
  Steve Speicher
  
  "Klotz, Leigh" <Leigh.Klotz@xerox.com> wrote on 03/28/2007 01:49:42 PM:
  
  > Steve,
  > We discussed this issue at today's teleconference and have some
  > observations and questions.
  > We believe that xsi:type cannot be used to contradict an
  > xf:model/@schema or xf:model/xsd:schema declaration, only to refine it
  > under rules specified normatively by XML Schema.
  > If you agree with this statement but think our wording conveys
  > otherwise, please read point 1.
  > If you believe that XForms can or should allow xsi:type to contradict an
  > author-specified schema, please read points 2, 3, and 4.
  > 1. We agree with you in general that "the wording is intended to state
  > that the node is valid if it passes valdation for both 1) External or
  > inline schema as possibly redefined by xsi:type 2) type MIP." However,
  > we don't agree that about "redefined."  There is no attempt to give
  > special meaning to xsi:type outside its definition in XML Schema.  All
  > use of xsi:type in instances is bound by XML Schema processing rules,
  > and is normatively defined there, not in XForms.  (But see point 4).
  > Instead of
  >    "the node satisfies all applicable XML schema definitions (including 
  >    those associated by the type model item property, by an external or
  > an   inline schema, *or* by xsi:type)"
  > Do you think it means the following?
  >    "the node satisfies all applicable XML schema definitions (including 
  >    those associated by the type model item property, by an external or
  > an   inline schema, *and* by xsi:type)"
  > If so, we hope that instead of re-issuing the erratum, you are satisfied
  > with our assertion here that it is XML Schema that normatively defines
  > xsi:type, not XForms.
  
  I am satisfied that XForms is not attempting to give special meaning to
  xsi:type.  Perhaps this can be clarified in 1.1 drafts?
  
  > 2. We do not understand the reference to "widely deployed usages of
  > validated XML  Instances."XML Schema defines xsi:type for the  
  > substutition, restriction, or
  > extension of existing types.
  > A document that attempts to override the type of an element with an
  > unrelated type is not valid.
  > According to XML Schema, only with a type defined by restriction or
  > extension, and in some cases by substitution.
  > Please see http://www.w3.org/TR/xmlschema-1/#cos-ct-derived-ok
  > To test this point, I've taken your example below and defined schema.xsd
  > which I think describes the case.
  > It defines a type for the child element which contains only other child
  > elements, and a type called "newType" that contains grandChild elements,
  > which themselves are xsd:string.
  > Here is the Schema:
  ..snip
  > When I attempt to validate the stuff.xml document with a Schema
  > processor I get this error:
  >   Element '{http://sample.com}child', attribute
  > '{http://www.w3.org/2001/XMLSchema-instance}type':  The type definition  
  > '{http://sample.com}newType', specified by
  > xsi:type, is blocked or not  validly derived from the type definition of  
  > the element declaration.
  >   Element '{http://sample.com}grandchild': This element is not expected.
  >  Expected is ( {http://sample.com}child ).
  >   stuff.xml fails to validate
  > Do you know of a situation in which a Schema processor would allow
  > xsi:type to declare a type for an element which is in conflict with the
  > Schema type definition?
  
  Only as you said by extension or restriction, which still can allow you to
  have instances that can't validate to be types.
  
  Take this schema for an example:
  
  <?xml version="1.0"?>
  <xsd:schema targetNamespace="http://sample.com"
           xmlns:s="http://sample.com"
           xmlns:xsd="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified">
           <xsd:element name="root">
                   <xsd:complexType>
                           <xsd:sequence minOccurs="1" maxOccurs="1">
                                   <xsd:element name="child"
  type="s:childType" />
                           </xsd:sequence>
                   </xsd:complexType>
           </xsd:element>
  
           <xsd:complexType name="childType">
                   <xsd:sequence minOccurs="0" maxOccurs="unbounded">
                           <xsd:element name="grandChild" type="xsd:string"
  />
                   </xsd:sequence>
           </xsd:complexType>
  
           <xsd:complexType name="newType">
                   <xsd:complexContent>
                           <xsd:restriction base="s:childType">
                                   <xsd:sequence minOccurs="0"
  maxOccurs="unbounded">
                                           <xsd:element name="grandChild"
  type="xsd:date" />
                                   </xsd:sequence>
                           </xsd:restriction>
                   </xsd:complexContent>
           </xsd:complexType>
  </xsd:schema>
  
  Then validating this instance:
  
  <?xml version="1.0" encoding="UTF-8"?>
     <root xmlns="http://sample.com"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://sample.com schema.xsd">
       <child xsi:type="newType">
         <grandChild>Stuff</grandChild>
       </child>
     </root>
  
  shows that the value "Stuff" is not a valid xsd:date, for example
  
  > 3. Standalone Xerces
  > By Standalone Xerces, do you mean that processing the stuff.xml file
  > without access to the ssample.xsd schema file validates?
  > Given that there is no Schema information available, and there is no
  > type definition for xsi:type either, I believe that the best Xerces can
  > do is declare that the document is well-formed, and cannot test its
  > validity.  Do you disagree with this?
  
  What I meant by "standalone", was validation done outside of an XForms
  processor.
  In the XML instance example I gave, it clearly indicated using
  xsi:schemaLocation which schema to validate against.  It should have
  access to the schema.xsd schema from a standalone validator, or at least
  an editing environment that supports XML validation.
  
  > 4. In Schema validation, it is user of the document who gets to decide
  > what Schema to use, not the document itself.
  > To do otherwise would negate the value of Schema validation, as
  > nefarious instance data could circumvent its own validation!
  > For this reason, Schema processors are allowed to ignore
  > xsi:schemaLocation attributes in documents.
  > See http://www.w3.org/TR/xmlschema-1/#schema-loc which states
  >   Unless directed otherwise, for example by the invoking application or
  > by command line option, ...
  > In XForms, we take the xf:model/@schema attribute and the xsd:schema
  > child elements of xf:model to be direction from the invoking
  > application.
  > By #1 above, the xsi:type attribute in the instance cannot specify
  > anything in conflict with the Schema specified by the form author, so we
  > conclude that the correct behavior is to fail to submit because the
  > document is not valid.
  >
  
  So if I understand what you are saying, these 2 statements are not equal:
  
  1)
  <xf:model schema="schema.xsd">
      <xf:instance>
         <t:root>...</t:root>
      </xf:instance>
  </xf:model>
  
  2)
  <xf:model>
     <xf:instance>
       <t:root xsi:schemaLocation="http://sample.com schema.xsd">...</root>
     </xf:instance>
  </xf:model>
  
  Since as the author of #1 indicates the overriding schema to use for
  validation and
  author of content of #2 indicates what schema to use for validating
  separate instance.
  Also XForms processors can not take the schema in #2 and treat as the
  @schema attribute on <xf:model>, as
  has to process any xsi:type[s].
  
  > Leigh.-----Original Message-----
  > From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
  > Behalf Of Steve K Speicher
  > Sent: Monday, March 26, 2007 3:42 PM
  > To: www-forms@w3.org
  > Subject: Re: 1.0 errata section 10 (complex type validation
  > clarification)
  > See thread
  > http://lists.w3.org/Archives/Public/www-forms/2006Aug/0047.html
  > and resulting errata 
  > http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E10a
  > I find that the definition for validation in the errata is too strict
  > anddoesn't match that of some widely deployed usages of validated XML 
  > instances.
  > Take for instance this example:
  >  <!-- simple sample XForms model -->
  >   <xf:model schema="schema.xsd">
  >     <xf:instance src="stuff.xml" />
  >   </xf:model>
  >  <!-- stuff.xml -->
  >   <root xmlns="http://sample.com"
  >     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  >     xsi:schemaLocation="http://sample.com schema.xsd">
  >     <child xsi:type="newType">
  >       <grandchild>Stuff</grandchild>
  >     </child>
  >   </root>
  > According to the errata it says:   "the node satisfies all applicable  
  > XML schema definitions (includingthose associated by the type model item  
  > property, by an external or aninline schema, or by xsi:type)"
  > If for example, my "newType" defines a conflicting complex content model
  > for <child> then there is no way for my instance to validate, therefore
  > itcan never be submitted.  If you validate the instance using a  
  > standalone
  > validator such as Xerces, it validates fine.
  > I believe the wording is intended to state that the node is valid if it 
  > passes validation for both these:
  >   1) external or inline schema, as possibly redefined by xsi:type
  >   2) type MIP
  > The errata wording seems to indicate that both external/inline schema
  > andxsi:type schema type definitions should be used.Regards,
  > Steve Speicher
  
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Steve,
  
  please see comments inline.
  
  > Leigh,
  > 
  > Thanks for the quick and thorough reply, I have responded inline.
  > 
  > Thanks,
  > Steve Speicher
  > 
  > "Klotz, Leigh" <Leigh.Klotz@xerox.com> wrote on 03/28/2007 01:49:42 PM:
  > 
  >> Steve,
  >> We discussed this issue at today's teleconference and have some
  >> observations and questions.
  >> We believe that xsi:type cannot be used to contradict an
  >> xf:model/@schema or xf:model/xsd:schema declaration, only to refine it
  >> under rules specified normatively by XML Schema.
  >> If you agree with this statement but think our wording conveys
  >> otherwise, please read point 1.
  >> If you believe that XForms can or should allow xsi:type to contradict an
  >> author-specified schema, please read points 2, 3, and 4.
  >> 1. We agree with you in general that "the wording is intended to state
  >> that the node is valid if it passes valdation for both 1) External or
  >> inline schema as possibly redefined by xsi:type 2) type MIP." However,
  >> we don't agree that about "redefined."  There is no attempt to give
  >> special meaning to xsi:type outside its definition in XML Schema.  All
  >> use of xsi:type in instances is bound by XML Schema processing rules,
  >> and is normatively defined there, not in XForms.  (But see point 4).
  >> Instead of
  >>    "the node satisfies all applicable XML schema definitions (including 
  >>    those associated by the type model item property, by an external or
  >> an   inline schema, *or* by xsi:type)"
  >> Do you think it means the following?
  >>    "the node satisfies all applicable XML schema definitions (including 
  >>    those associated by the type model item property, by an external or
  >> an   inline schema, *and* by xsi:type)"
  >> If so, we hope that instead of re-issuing the erratum, you are satisfied
  >> with our assertion here that it is XML Schema that normatively defines
  >> xsi:type, not XForms.
  > 
  > I am satisfied that XForms is not attempting to give special meaning to
  > xsi:type.  Perhaps this can be clarified in 1.1 drafts?
  > 
  
  We clarified it, see
  http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#model-using-atomic
  for changes.
  
  >> 2. We do not understand the reference to "widely deployed usages of
  >> validated XML  Instances."XML Schema defines xsi:type for the  
  >> substutition, restriction, or
  >> extension of existing types.
  >> A document that attempts to override the type of an element with an
  >> unrelated type is not valid.
  >> According to XML Schema, only with a type defined by restriction or
  >> extension, and in some cases by substitution.
  >> Please see http://www.w3.org/TR/xmlschema-1/#cos-ct-derived-ok
  >> To test this point, I've taken your example below and defined schema.xsd
  >> which I think describes the case.
  >> It defines a type for the child element which contains only other child
  >> elements, and a type called "newType" that contains grandChild elements,
  >> which themselves are xsd:string.
  >> Here is the Schema:
  > ..snip
  >> When I attempt to validate the stuff.xml document with a Schema
  >> processor I get this error:
  >>   Element '{http://sample.com}child', attribute
  >> '{http://www.w3.org/2001/XMLSchema-instance}type':  The type definition  
  >> '{http://sample.com}newType', specified by
  >> xsi:type, is blocked or not  validly derived from the type definition of  
  >> the element declaration.
  >>   Element '{http://sample.com}grandchild': This element is not expected.
  >>  Expected is ( {http://sample.com}child ).
  >>   stuff.xml fails to validate
  >> Do you know of a situation in which a Schema processor would allow
  >> xsi:type to declare a type for an element which is in conflict with the
  >> Schema type definition?
  > 
  > Only as you said by extension or restriction, which still can allow you to
  > have instances that can't validate to be types.
  > 
  > Take this schema for an example:
  > 
  > <?xml version="1.0"?>
  > <xsd:schema targetNamespace="http://sample.com"
  >          xmlns:s="http://sample.com"
  >          xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  >          elementFormDefault="qualified">
  >          <xsd:element name="root">
  >                  <xsd:complexType>
  >                          <xsd:sequence minOccurs="1" maxOccurs="1">
  >                                  <xsd:element name="child"
  > type="s:childType" />
  >                          </xsd:sequence>
  >                  </xsd:complexType>
  >          </xsd:element>
  > 
  >          <xsd:complexType name="childType">
  >                  <xsd:sequence minOccurs="0" maxOccurs="unbounded">
  >                          <xsd:element name="grandChild" type="xsd:string"
  > />
  >                  </xsd:sequence>
  >          </xsd:complexType>
  > 
  >          <xsd:complexType name="newType">
  >                  <xsd:complexContent>
  >                          <xsd:restriction base="s:childType">
  >                                  <xsd:sequence minOccurs="0"
  > maxOccurs="unbounded">
  >                                          <xsd:element name="grandChild"
  > type="xsd:date" />
  >                                  </xsd:sequence>
  >                          </xsd:restriction>
  >                  </xsd:complexContent>
  >          </xsd:complexType>
  > </xsd:schema>
  > 
  > Then validating this instance:
  > 
  > <?xml version="1.0" encoding="UTF-8"?>
  >    <root xmlns="http://sample.com"
  >      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  >      xsi:schemaLocation="http://sample.com schema.xsd">
  >      <child xsi:type="newType">
  >        <grandChild>Stuff</grandChild>
  >      </child>
  >    </root>
  > 
  > shows that the value "Stuff" is not a valid xsd:date, for example
  > 
  
  Yes, we agree.
  
  >> 3. Standalone Xerces
  >> By Standalone Xerces, do you mean that processing the stuff.xml file
  >> without access to the ssample.xsd schema file validates?
  >> Given that there is no Schema information available, and there is no
  >> type definition for xsi:type either, I believe that the best Xerces can
  >> do is declare that the document is well-formed, and cannot test its
  >> validity.  Do you disagree with this?
  > 
  > What I meant by "standalone", was validation done outside of an XForms
  > processor.
  > In the XML instance example I gave, it clearly indicated using
  > xsi:schemaLocation which schema to validate against.  It should have
  > access to the schema.xsd schema from a standalone validator, or at least
  > an editing environment that supports XML validation.
  > 
  
  We agree. If you're using an instance outside XForms you can turn on Schema
  validation by using xsi:schemaLocation. Note that this is only a hint to the
  Schema processor, it is allowed to ignore the hint (see
  http://www.w3.org/TR/xmlschema11-1/#xsi_schemaLocation for reference).
  
  >> 4. In Schema validation, it is user of the document who gets to decide
  >> what Schema to use, not the document itself.
  >> To do otherwise would negate the value of Schema validation, as
  >> nefarious instance data could circumvent its own validation!
  >> For this reason, Schema processors are allowed to ignore
  >> xsi:schemaLocation attributes in documents.
  >> See http://www.w3.org/TR/xmlschema-1/#schema-loc which states
  >>   Unless directed otherwise, for example by the invoking application or
  >> by command line option, ...
  >> In XForms, we take the xf:model/@schema attribute and the xsd:schema
  >> child elements of xf:model to be direction from the invoking
  >> application.
  >> By #1 above, the xsi:type attribute in the instance cannot specify
  >> anything in conflict with the Schema specified by the form author, so we
  >> conclude that the correct behavior is to fail to submit because the
  >> document is not valid.
  >>
  > 
  > So if I understand what you are saying, these 2 statements are not equal:
  > 
  > 1)
  > <xf:model schema="schema.xsd">
  >     <xf:instance>
  >        <t:root>...</t:root>
  >     </xf:instance>
  > </xf:model>
  > 
  > 2)
  > <xf:model>
  >    <xf:instance>
  >      <t:root xsi:schemaLocation="http://sample.com schema.xsd">...</root>
  >    </xf:instance>
  > </xf:model>
  > 
  > Since as the author of #1 indicates the overriding schema to use for
  > validation and
  > author of content of #2 indicates what schema to use for validating
  > separate instance.
  > Also XForms processors can not take the schema in #2 and treat as the
  > @schema attribute on <xf:model>, as
  > has to process any xsi:type[s].
  > 
  
  Yes, you are right. XForms processors ignore any xsi:schemaLocation hints. So
  it's the responsibility of the form author to provide a schema attribute on
  element xf:model in order to process xsi:type attributes in terms of
  validation.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  >> Leigh.-----Original Message-----
  >> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
  >> Behalf Of Steve K Speicher
  >> Sent: Monday, March 26, 2007 3:42 PM
  >> To: www-forms@w3.org
  >> Subject: Re: 1.0 errata section 10 (complex type validation
  >> clarification)
  >> See thread
  >> http://lists.w3.org/Archives/Public/www-forms/2006Aug/0047.html
  >> and resulting errata 
  >> http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E10a
  >> I find that the definition for validation in the errata is too strict
  >> anddoesn't match that of some widely deployed usages of validated XML 
  >> instances.
  >> Take for instance this example:
  >>  <!-- simple sample XForms model -->
  >>   <xf:model schema="schema.xsd">
  >>     <xf:instance src="stuff.xml" />
  >>   </xf:model>
  >>  <!-- stuff.xml -->
  >>   <root xmlns="http://sample.com"
  >>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  >>     xsi:schemaLocation="http://sample.com schema.xsd">
  >>     <child xsi:type="newType">
  >>       <grandchild>Stuff</grandchild>
  >>     </child>
  >>   </root>
  >> According to the errata it says:   "the node satisfies all applicable  
  >> XML schema definitions (includingthose associated by the type model item  
  >> property, by an external or aninline schema, or by xsi:type)"
  >> If for example, my "newType" defines a conflicting complex content model
  >> for <child> then there is no way for my instance to validate, therefore
  >> itcan never be submitted.  If you validate the instance using a  
  >> standalone
  >> validator such as Xerces, it validates fine.
  >> I believe the wording is intended to state that the node is valid if it 
  >> passes validation for both these:
  >>   1) external or inline schema, as possibly redefined by xsi:type
  >>   2) type MIP
  >> The errata wording seems to indicate that both external/inline schema
  >> andxsi:type schema type definitions should be used.Regards,
  >> Steve Speicher

13.10 Nillable complex type with simple content

PROBLEM ID: 92

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

NOTES:

  We clarified in the spec that nillable is not applicable to the type MIP because
  schema associates it with element validity, not type validity.

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  I am sending this following an interesting comment about schema types
   from a user.
  
  XForms 1.1 specifies that:
  
      "The type model item property associates a datatype (as defined in
       [XML Schema part 2]) with the string-value (as defined in [XPath
       1.0]) of an instance node. The datatype being associated can be
       obtained from a simpleType definition or a simpleContent definition
       from a complexType. If the datatype cannot be obtained as just
       described, then the Default Value of xsd:string is used."
  
  Now, I assume that this means I can write something like this:
  
        <xs:element name="state-element">
            <xs:complexType>
                <xs:simpleContent>
                    <xs:extension base="test:state-type">
                       <xs:attribute name="code" type="xs:integer"/>
                    </xs:extension>
                </xs:simpleContent>
            </xs:complexType>
        </xs:element>
  
  use it as follows:
  
        <xforms:bind nodeset="state" type="test:state-element"/>
  
  and I should expect the validator to validate the content of my
  <state> instance element using the datatype part of my xs:element
  definition.
  
  First, is this correct?
  
  Second, what if my type is as follows instead:
  
        <xs:element name="state-element" nillable="true">
            <xs:complexType>
                <xs:simpleContent>
                    <xs:extension base="test:state-type">
                       <xs:attribute name="code" type="xs:integer"/>
                    </xs:extension>
                </xs:simpleContent>
            </xs:complexType>
        </xs:element>
  
  and my instance element:
  
      <state xsi:nil="true">CA</state>
  
  Is XForms supposed to honor xsi:nil in this case, and accept an empty
  content for <state>?
  
  My guess is that it is not in fact part of the dataype. XML Schema says:
  
      "If {nillable} is true, then an element may also be ·valid· if it
       carries the namespace qualified attribute with [local name] nil
       from namespace http://www.w3.org/2001/XMLSchema-instance and value
       true (see xsi:nil (§2.6.2)) even if it has no text or element
       content despite a {content type} which would otherwise require
       content."
  
  So the nil thing seems to apply to the validity of the element, not of
  its datatype part.
  
  However, after all the form author is binding a nillable element type
  to an XForms instance element, and it is not very intuitive that
  xsi:nil won't work in this case.
  
  Whatever the answer, I think that it would be very valuable to clarify
  this in the spec.
  
  -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,
  
  This is a very technically interesting issue you have raised.
  
  The working group agrees that nillable appears to be a statement about the
  content of an element. However, our hands are a bit tied here because XML Schema
  Part 1 Section 3.3.4 associates the notion of nillable with "Element Locally
  Valid (Element)" and not "Element Locally Valid (Type)".  By comparison, XForms
  associates the type MIP with the type validation, and more specifically with the
  simple content part of a schema type.
  
  Hence, we agree with your assessment that a type MIP assignment does not
  associate nillable with a node.  Moreover, a clarification note in the
  specification does not appear to be necessary because a type MIP also *cannot*
  refer to an element declaration, which is the only place where nillable can
  occur in an XML schema.  Because nillable is associated with element validity
  and not type validity, it cannot be attached to a schema type declaration.  
  
  If your schema below were modified to include a named complexType for
  "state-element", it would be clearer that the nillable attribute is attached to
  the xs:element that declares "state-element" and not the complexType for
  "state-element".  However, this modification is necessary in order for you to
  have a correct XForm, as the type MIP must refer to the complexType for
  "state-element" and not the element declaration itself.
  
  Please let us know if you have any further concerns about this issue.
  
  Thank you,
  John Boyer
  
  > 
  > All,
  > 
  > I am sending this following an interesting comment about schema types
  >  from a user.
  > 
  > XForms 1.1 specifies that:
  > 
  >     "The type model item property associates a datatype (as defined in
  >      [XML Schema part 2]) with the string-value (as defined in [XPath
  >      1.0]) of an instance node. The datatype being associated can be
  >      obtained from a simpleType definition or a simpleContent definition
  >      from a complexType. If the datatype cannot be obtained as just
  >      described, then the Default Value of xsd:string is used."
  > 
  > Now, I assume that this means I can write something like this:
  > 
  >       <xs:element name="state-element">
  >           <xs:complexType>
  >               <xs:simpleContent>
  >                   <xs:extension base="test:state-type">
  >                      <xs:attribute name="code" type="xs:integer"/>
  >                   </xs:extension>
  >               </xs:simpleContent>
  >           </xs:complexType>
  >       </xs:element>
  > 
  > use it as follows:
  > 
  >       <xforms:bind nodeset="state" type="test:state-element"/>
  > 
  > and I should expect the validator to validate the content of my
  > <state> instance element using the datatype part of my xs:element
  > definition.
  > 
  > First, is this correct?
  > 
  > Second, what if my type is as follows instead:
  > 
  >       <xs:element name="state-element" nillable="true">
  >           <xs:complexType>
  >               <xs:simpleContent>
  >                   <xs:extension base="test:state-type">
  >                      <xs:attribute name="code" type="xs:integer"/>
  >                   </xs:extension>
  >               </xs:simpleContent>
  >           </xs:complexType>
  >       </xs:element>
  > 
  > and my instance element:
  > 
  >     <state xsi:nil="true">CA</state>
  > 
  > Is XForms supposed to honor xsi:nil in this case, and accept an empty
  > content for <state>?
  > 
  > My guess is that it is not in fact part of the dataype. XML Schema says:
  > 
  >     "If {nillable} is true, then an element may also be ?valid? if it
  >      carries the namespace qualified attribute with [local name] nil
  >      from namespace http://www.w3.org/2001/XMLSchema-instance and value
  >      true (see xsi:nil (?2.6.2)) even if it has no text or element
  >      content despite a {content type} which would otherwise require
  >      content."
  > 
  > So the nil thing seems to apply to the validity of the element, not of
  > its datatype part.
  > 
  > However, after all the form author is binding a nillable element type
  > to an XForms instance element, and it is not very intuitive that
  > xsi:nil won't work in this case.
  > 
  > Whatever the answer, I think that it would be very valuable to clarify
  > this in the spec.
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

13.11 [LC: Editorial] 5.2.5 xforms:email

PROBLEM ID: 97

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

NOTES:

  Proposed changes (by nvdbleek):
  
  Add the following example to the "Examples of invalid xforms:email addresses"
  mailto:editors@example.com
  
  Add the following note 
  mailto:editors@example.com is a valid xsd:anyURI but is not valid xforms:email

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  
  http://www.w3.org/TR/xforms11/#email-type
  
  Please add to the "Examples of invalid xforms:email addresses"
  
  	mailto:editors@example.com
  
  (and point out, maybe, that this is a valid anyURI)
  
  Steven
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  These have been done and can now be found in the editor's draft available from
  the working group home pages.
  
  Best regards,
  John Boyer
  
  > 
  > 
  > http://www.w3.org/TR/xforms11/#email-type
  > 
  > Please add to the "Examples of invalid xforms:email addresses"
  > 
  > 	mailto:editors@example.com
  > 
  > (and point out, maybe, that this is a valid anyURI)
  > 
  > Steven
  > 
  > 

13.12 Fw: Confusion on datatypes with empty content

PROBLEM ID: 22

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

ORIGINAL MESSAGE:

  From: "Gary F Stevens" <gfsteven@us.ibm.com>
  
  ------------ha3xB2oVlVbZrkN7gai8Pf
  Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
  Content-Transfer-Encoding: 7bit
  
  
  
  
  
  
  
  ----- Forwarded by Gary F Stevens/Raleigh/IBM on 04/13/2007 12:06 PM -----
  
                Gary F
                Stevens/Raleigh/I
                BM                                                         To
                                          www-forms@w3.org
                04/12/2007 01:38                                           cc
                PM
                                                                      Subject
                                          Confusion on datatypes with empty
                                          content
  
  
  
  
  
  
  
  
  
  Hello,
  
  While reading through the XForms 1.1 specification I became confused by the
  language describing datatypes which allow empty content in section 5.2.7.
  The second paragraph of the description seems to contradict the first
  paragraph.  While the first paragraph says "The following XForms datatypes
  are defined to allow either empty content or the content allowed by the
  corresponding XML schema datatype" the second paragraph says "The indicated
  XForms datatypes do not allow empty string content and some others already
  accepted empty string data".
  
  Gary F Stevens
  Software Group - Emerging Standards
  IBM/US/Raleigh-RTP
  ------------ha3xB2oVlVbZrkN7gai8Pf
  Content-Disposition: attachment; filename=ecblank.gif
  Content-Type: image/gif; name=ecblank.gif
  Content-Transfer-Encoding: Base64
  
  R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7
  ------------ha3xB2oVlVbZrkN7gai8Pf
  Content-Disposition: attachment; filename=attachment955.htm
  Content-Type: text/html; name=attachment955.htm
  Content-Transfer-Encoding: Quoted-Printable
  
  <html><body>
  <p><font size=3D"2" color=3D"#800080">----- Forwarded by Gary F Stevens/=
  Raleigh/IBM</font><font size=3D"2" color=3D"#800080"> on 04/13/2007 12:0=
  6 PM</font><font size=3D"2" color=3D"#800080"> -----</font><br>
  <br>
  
  <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
  <tr valign=3D"top"><td style=3D"background-image:url(cid:1__=3D08BBF82FD=
  FCBE6E08f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " width=3D=
  "40%">
  <ul>
  <ul>
  <ul>
  <ul><b><font size=3D"2">Gary F Stevens/Raleigh/IBM</font></b><font size=3D=
  "2"> </font>
  <p><font size=3D"2">04/12/2007 01:38 PM</font></ul>
  </ul>
  </ul>
  </ul>
  </td><td width=3D"60%">
  <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
  <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D=
  "cid:2__=3D08BBF82FDFCBE6E08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
  ""><br>
  <div align=3D"right"><font size=3D"2">To</font></div></td><td width=3D"1=
  00%"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D08BBF82FDFCBE6E08f9e=
  8a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
  <font size=3D"2">www-forms@w3.org</font></td></tr>
  
  <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D=
  "cid:2__=3D08BBF82FDFCBE6E08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
  ""><br>
  <div align=3D"right"><font size=3D"2">cc</font></div></td><td width=3D"1=
  00%"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D08BBF82FDFCBE6E08f9e=
  8a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
  </td></tr>
  
  <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D=
  "cid:2__=3D08BBF82FDFCBE6E08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
  ""><br>
  <div align=3D"right"><font size=3D"2">Subject</font></div></td><td width=
  =3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D08BBF82FDFCBE6E=
  08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D""><br>
  <font size=3D"2">Confusion on datatypes with empty content</font></td></=
  tr>
  </table>
  
  <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
  <tr valign=3D"top"><td width=3D"58"><img width=3D"1" height=3D"1" src=3D=
  "cid:2__=3D08BBF82FDFCBE6E08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D=
  ""></td><td width=3D"336"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D=
  08BBF82FDFCBE6E08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D""></td></t=
  r>
  </table>
  </td></tr>
  </table>
  Hello,<br>
  <br>
  While reading through the XForms 1.1 specification I became confused by =
  the language describing datatypes which allow empty content in section 5=
  .2.7. The second paragraph of the description seems to contradict the fi=
  rst paragraph.  While the first paragraph says &quot;The following XForm=
  s datatypes are defined to allow either empty content or the content all=
  owed by the corresponding XML schema datatype&quot; the second paragraph=
   says &quot;The indicated XForms datatypes do not allow empty string con=
  tent and some others already accepted empty string data&quot;.<br>
  <br>
  Gary F Stevens<br>
  Software Group - Emerging Standards<br>
  IBM/US/Raleigh-RTP</body></html>
  
  ------------ha3xB2oVlVbZrkN7gai8Pf--
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  Many thanks for this comment. We agree that it was confusing.
  
  We have reworded this to make it clear that all the datatypes allow empty.
  
  Best wishes,
  
  Steven Pemberton
  For the Forms WG
  
  > While reading through the XForms 1.1 specification I became confused by the
  > language describing datatypes which allow empty content in section 5.2.7.
  > The second paragraph of the description seems to contradict the first
  > paragraph.  While the first paragraph says "The following XForms datatypes
  > are defined to allow either empty content or the content allowed by the
  > corresponding XML schema datatype" the second paragraph says "The indicated
  > XForms datatypes do not allow empty string content and some others already
  > accepted empty string data".

13.13 [LC] 5.2 XForms Datatypes

PROBLEM ID: 62

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/#datatypes-xforms
  
  Since these are all in the XForms namespace, then the prefix is
  presumably optional, so I can write the following with impunity:
  
         <bind nodeset="size" type="integer" />
  
  Hooray! Please point this out.
  
  

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/#datatypes-xforms
  > 
  > Since these are all in the XForms namespace, then the prefix is
  > presumably optional, so I can write the following with impunity:
  > 
  >        <bind nodeset="size" type="integer" />
  > 
  > Hooray! Please point this out.
  > 
  > 
  > 

14. UI

14.1 LC: Issues with repeat index manipulation and generalized insert/delete actions

PROBLEM ID: 21

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

NOTES:

  This is only substantive in that it describes semantic changes that affect the
  meaning of elements related to repeat index management.  However, we do not
  expect objections as this change is necessary to make repeat index management
  work correctly in all cases and to achieve the WG objective of generalizing
  insert/delete, which includes removing behaviors not related to data mutation
  from insert/delete.  Current implementations of 1.0 are making index mgmt work
  in most or all cases using strategies similar or identical to those now
  described, so the prior text was inadequate at reflecting best practice.
  
  Detailed notes:
  The working group resolved to accept this LC comment, assigning Action
  2007-08-15.3 to John.  The working group further resolved that the solution
  must
  accommodate the content of
  http://lists.w3.org/Archives/Public/public-forms/2007Aug/0038.html

ORIGINAL MESSAGE:

  From: "John Boyer" <boyerj@ca.ibm.com>
  
  Three issues regarding Section 9.3.5 and 9.3.6 (and technically 9.3.1):
  
  1) When insert or delete actions occur, the repeat index is updated for
  any repeat bound to node(s) inserted or deleted.
  
  Currently, this is described in the insert and delete actions, which is
  inappropriate since it is a property of repeats.  The intent of insert and
  delete in XForms 1.1 is to be generalized data manipulators, so they
  should not contain language about manipulating repeat indices.
  
  Moreover, now that we have the proper context information in xforms-insert
  and xforms-delete it is even possible to describe how repeat index
  manipulation could be achieved by having repeat semantics imply listeners
  for xforms-insert and xforms-delete with index update according to whether
  the nodes listed are applicable to the given repeat.
  
  Although this is an implementation, I think it is important to preserve
  the property that the repeat indices are updated immediately (as is the
  case now) and not at some later time that might seem more obvious, such as
  xforms-refresh.
  
  
  2) It is completely unacceptable to me that the index of a nested repeat
  is reset when its containing repeat's index is updated.  This behavior
  should simply be stricken from XForms 1.1 as there is no earthly reason
  for doing it.
  
  I believe it was added to XForms 1.0 at a time when repeating was not
  nearly as well understood as it is now.  I believe there was the thought
  that there would only exist one instance of a data structure to represent
  any repeat, including an inner repeat,  Hence the index of that object
  would be changed to the start value in a newly inserted repeat item
  (9.3.5, bullet 8).  I believe similar reasoning was used to arrive at
  inner repeat reinitialization in the delete case (9.3.6 bullet 5).
  
  However, we now know that inner repeats are similar to inner switches in
  an outer repeat.  Just as the selected case of a switch may be different
  in each repeat item, the index of an inner repeat may be different in each
  repeat item.  Hence there is no need to modify the indexes of inner
  repeats when a repeat item in the outer repeat is created or destroyed,
  just as there is no need to reset the cases of all switches in all repeat
  items just because one is added or deleted.
  
  Alternately, observe that if the inner repeat index adjustment really were
  necessary on insert and delete, then there would be a flaw in that case
  adjustment of repeated switches would also be needed, and the spec makes
  no allowance for this.
  
  The proposed solution is that XForms should retain only the simpler
  behavior which says that a repeat index is updated if the context node of
  the indexed repeat item is deleted or if a new node is inserted into the
  
  
  3) Insert and Delete are now in the wrong section.
  
  In XForms 1.1, insert and delete have become generalized data
  manipulators.  They are not really tied to repeat anymore in that we do
  suggest their use in other cases, like extracting the data payload from a
  SOAP envelope.  To avoid confusion that insert/delete should only be used
  with repeated data, they should be moved to Section 10.
  
  This of course is another good argument for moving the index updating
  logic to repeat in 9.3.1.
  
  
  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>
  
  The working group accepted this LC comment, and further requested in the
  resulting action item (Action 2007-08-15.3) that the content of
  http://lists.w3.org/Archives/Public/public-forms/2007Aug/0038.html should be
  accounted for.
  
  The solution has been implemented and now appears in the editor's draft
  available from the working group homepage.  See in particular sections 9.3.3 and
  9.3.4 of the specification for language about repeat index management during
  repeat processing and user interaction, and note that the insert and delete
  actions have been moved to Section 10 and stripped of language pertaining to
  repeat index management (except for notes referring the reader back to Section
  9.3.3).
  
  John Boyer
  
  > Three issues regarding Section 9.3.5 and 9.3.6 (and technically 9.3.1):
  > 
  > 1) When insert or delete actions occur, the repeat index is updated for
  > any repeat bound to node(s) inserted or deleted.
  > 
  > Currently, this is described in the insert and delete actions, which is
  > inappropriate since it is a property of repeats.  The intent of insert and
  > delete in XForms 1.1 is to be generalized data manipulators, so they
  > should not contain language about manipulating repeat indices.
  > 
  > Moreover, now that we have the proper context information in xforms-insert
  > and xforms-delete it is even possible to describe how repeat index
  > manipulation could be achieved by having repeat semantics imply listeners
  > for xforms-insert and xforms-delete with index update according to whether
  > the nodes listed are applicable to the given repeat.
  > 
  > Although this is an implementation, I think it is important to preserve
  > the property that the repeat indices are updated immediately (as is the
  > case now) and not at some later time that might seem more obvious, such as
  > xforms-refresh.
  > 
  > 
  > 2) It is completely unacceptable to me that the index of a nested repeat
  > is reset when its containing repeat's index is updated.  This behavior
  > should simply be stricken from XForms 1.1 as there is no earthly reason
  > for doing it.
  > 
  > I believe it was added to XForms 1.0 at a time when repeating was not
  > nearly as well understood as it is now.  I believe there was the thought
  > that there would only exist one instance of a data structure to represent
  > any repeat, including an inner repeat,  Hence the index of that object
  > would be changed to the start value in a newly inserted repeat item
  > (9.3.5, bullet 8).  I believe similar reasoning was used to arrive at
  > inner repeat reinitialization in the delete case (9.3.6 bullet 5).
  > 
  > However, we now know that inner repeats are similar to inner switches in
  > an outer repeat.  Just as the selected case of a switch may be different
  > in each repeat item, the index of an inner repeat may be different in each
  > repeat item.  Hence there is no need to modify the indexes of inner
  > repeats when a repeat item in the outer repeat is created or destroyed,
  > just as there is no need to reset the cases of all switches in all repeat
  > items just because one is added or deleted.
  > 
  > Alternately, observe that if the inner repeat index adjustment really were
  > necessary on insert and delete, then there would be a flaw in that case
  > adjustment of repeated switches would also be needed, and the spec makes
  > no allowance for this.
  > 
  > The proposed solution is that XForms should retain only the simpler
  > behavior which says that a repeat index is updated if the context node of
  > the indexed repeat item is deleted or if a new node is inserted into the
  > 
  > 
  > 3) Insert and Delete are now in the wrong section.
  > 
  > In XForms 1.1, insert and delete have become generalized data
  > manipulators.  They are not really tied to repeat anymore in that we do
  > suggest their use in other cases, like extracting the data payload from a
  > SOAP envelope.  To avoid confusion that insert/delete should only be used
  > with repeated data, they should be moved to Section 10.
  > 
  > This of course is another good argument for moving the index updating
  > logic to repeat in 9.3.1.
  > 
  > 
  > 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
  > 
  > 

14.2 removal of the notion of a homogeneous collection from XForms 1.1 WD

PROBLEM ID: 3

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

NOTES:

  This is substantive in that it changes behavior of the nodeset binding of
  repeat, but we expect no objection as the WG is unanimously in favor of this and
  indeed most implementers of 1.0 do not observe the homogeneous collection
  limitation (which 1.0 left 'undefined' to allow implementers to try it out). 
  This changes is also consisten with the generalizations made to insert and
  delete actions.

ORIGINAL MESSAGE:

  From: "Joern Turner" <joern.turner@dreamlab.net>
  
  
  During February 28, 2007 telecon the usefulness of the notion of a
  homogeneous collection was discussed. Members agreed to remove this
  notion from XForms 1.1 WD completely cause:
  
  - it's confusing to users
  - the definition of continuity of elements is weak as John pointed out
  (existence of text nodes in between elements)
  - it is not considered a performance issue by implementors
  - it constrains form authors in certain use cases
  
  

FOLLOWUP 1:

  From: www-forms-editor-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:
  ----------------------------------------------------------------------------
  
  
  > During February 28, 2007 telecon the usefulness of the notion of a
  > homogeneous collection was discussed. Members agreed to remove this
  > notion from XForms 1.1 WD completely cause:
  > 
  > - it's confusing to users
  > - the definition of continuity of elements is weak as John pointed out
  > (existence of text nodes in between elements)
  > - it is not considered a performance issue by implementors
  > - it constrains form authors in certain use cases
  
  Joern,
  
  Thanks for your comment. At the Forms WG meeting today the WG agreed with your
  suggestion, and will adopt it.
  
  Many thanks.
  
  Steven Pemberton
  For the Forms WG
  
  

REPLY 1:

  From: Steven Pemberton <xforms-issues@mn.aptest.com>
  
  > During February 28, 2007 telecon the usefulness of the notion of a
  > homogeneous collection was discussed. Members agreed to remove this
  > notion from XForms 1.1 WD completely cause:
  > 
  > - it's confusing to users
  > - the definition of continuity of elements is weak as John pointed out
  > (existence of text nodes in between elements)
  > - it is not considered a performance issue by implementors
  > - it constrains form authors in certain use cases
  
  Joern,
  
  Thanks for your comment. At the Forms WG meeting today the WG agreed with your
  suggestion, and will adopt it.
  
  Many thanks.
  
  Steven Pemberton
  For the Forms WG

REPLY 2:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  The working group agreed to the removal of the paragraph.
  
  > The following paragraph in section 9.3.8 should be removed:
  > 
  > The binding expression attached to the repeating sequence returns a
  > node-set of the collection being populated, not an individual node. Within
  > the body of element repeat, binding expressions are evaluated with a
  > context node of the node determined by the index. Repeat processing uses
  > XPath expressions to address the collection over which element repeat
  > operates.
  > 
  > The first and third sentences are obvious given other material in Section
  > 9, and the second sentence is old and wrong, contradicting the copious
  > material in Section 7.4 on evaluation context (see esp. point 2c and 2d in
  > 7.4).
  > 
  > 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 3:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  Spec ready solutions are now available for both of these issues in the editor's
  draft. [1] (9.3.3 Repeat Processing and 9.3.6 The itemset Element)
  
  35) We clarified in a note that all template content (including actions) are
  made
  unavailable to the host language processor.  So handlers declared within a
  repeat do not handle elements dispatched to the repeat (and likewise for
  itemset).  Actions declared within a repeat template operate over the repeated
  content (e.g. the item elements generated by an itemset).
  
  36) The actions within an itemset *are* applicable to each item generated.  The
  sentence claiming that actions in the itemset don't handle events on
  the itemset has been changed to simply state that, as with repeat, handlers
  defined
  within itemset do not handle events on the itemset.
  
  This is necessary to prevent a double run of event handlers as events bubble up
  from generated content to the generating repeat or itemset.
  
  An example of how to handle events dispatched to a repeat or itemset was added.
  
  Regards,
  
  Nick Van den Bleeken
  [1] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-repeat-module
  
  > Full_Name: Aaron Reed
  > Submission from: (NULL) (32.97.110.142)
  > Submitted by: boyerj
  > 
  > 
  > 35) Section 9.3.2 - how should we handle XML event handlers contained at
  > root level under a repeat or a non-xforms element with repeat attrs?  Like
  > itemset (listeners registered on the repeat rows and not on the repeat
  > itself)?
  > 
  > 36) Section 9.3.3 - "An XForms processor must not allow XForms Actions
  > contained by an itemset to handle events on the itemset."  It seems odd
  > that an XForms action OUTSIDE the itemset can handle events on the itemset.
  > And non-XForms actions in the itemset won't be repeated under the anonymous
  > items.  For example, the xhtml or xml events 'handler' element would be
  > nice to have repeated to allow the form author to handle xforms-select and
  > xforms-deselect events with script.
  > 
  > 

14.3 LC: Issue with repeat index and rebuild

PROBLEM ID: 24

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

NOTES:

  John was in the room and agreed with the defer of automatically detecting when
  to flag a rebuild on repeat index change.
  
  Subsequent work to rigorously define "dynamic dependency" have substantially
  clarified exactly what kind of dependencies are created by index() invocations.
  Invocation in a model expression does *not* cause a rebuild.  However, all
  changes of index, including ones caused by focus change, set the recalculate
  etc. flags.  Also invocations of index() create a dependency to implicit
  instance data representing the repeat index, so setindex is like a setvalue. 
  This makes it crystal clear that index() used in a UI binding *is* supposed to
  be dynamically updated, but index() used in a model binding or compute does not
  signal a rebuild.

ORIGINAL MESSAGE:

  From: "John Boyer" <boyerj@ca.ibm.com>
  
  I seem to recall some years-old discussions about the effect of a repeat
  index change on the XForms processor.
  
  I seem to recall a face to face discussion in which it was suggested that
  a repeat index change should correspond to an automatic rebuild because
  bind nodesets or MIP expressions may contain invocations of the index()
  function.  I also recall the conversation indicating that implementations
  could do something more optimized that a full rebuild, such as focusing on
  binds that actually invoke index() on the affected repeat since those that
  don't would be unaffected.
  
  However, note that XForms 1.0 SE and XForms 1.1 both now say (in 9.3.8)
  that changing the focus to a control in a repeat item (row) other than the
  indexed repeat item does cause the repeat index to implicitly change.  In
  combination with the statement above, this would mean an implicit
  rebuild-recalculate-revalidate-refresh based.  Moreover, changing focus
  may change the index of multiple repeats that are nested, so one's spidey
  sense gets the tingle of another optimization.
  
  But the problem is that I cannot find any language in the XForms spec that
  even implies a connection between repeat index changes and automatic
  rebuilding.  For the record, I think the connection between repeat index
  and rebuild is wrong, and I was going to write a last call comment to
  suggest its removal.  But alas I have been foiled by the fact that it
  already doesn't seem to exist in the spec.  If someone can find this,
  please let me know; otherwise I will proceed on the assumption that the
  spec does not follow a repeat index change with an automatic rebuild.
  
  I believe that the original discussion about automatically rebuilding on
  index change was held, at least in part, from a desire to correct for the
  fact that index() *could be* invoked from the XPaths within an XForms bind
  (i.e. from model binding expressions).
  
  However, since such automatic rebuild is ultimately doomed to failure
  (because of automatic index changes on focus change in 9.3.8), it seems
  better to consider restricting the index() function to only being used in
  certain cases.  Clearly, the index() function was designed for use in the
  XPaths of XForms actions.  When index() is used in a UI binding, it is
  possible though somewhat difficult to create problems due to the staleness
  of the result.  More significant problems are easier to produce when
  index() is used in a model binding expression.
  
  In the past, this would have been hard, but XForms now requires different
  exception behavior based on where an XPath is located. For example, in
  Section 7.1, the choice of a binding exception versus a compute exception
  is based on where the XPath is located.  An invocation of index()
  appearing in any XPath other than those used in XForms actions should
  either produce NaN or preferrably an appropriate exception.
  
  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: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Hi John,
  
  We acknowledge the problem, but we have decided to defer this to a future
  version.
  
  Regards,
  
  Nick Van den Bleeken 
  
  > I seem to recall some years-old discussions about the effect of a repeat
  > index change on the XForms processor.
  > 
  > I seem to recall a face to face discussion in which it was suggested that
  > a repeat index change should correspond to an automatic rebuild because
  > bind nodesets or MIP expressions may contain invocations of the index()
  > function.  I also recall the conversation indicating that implementations
  > could do something more optimized that a full rebuild, such as focusing on
  > binds that actually invoke index() on the affected repeat since those that
  > don't would be unaffected.
  > 
  > However, note that XForms 1.0 SE and XForms 1.1 both now say (in 9.3.8)
  > that changing the focus to a control in a repeat item (row) other than the
  > indexed repeat item does cause the repeat index to implicitly change.  In
  > combination with the statement above, this would mean an implicit
  > rebuild-recalculate-revalidate-refresh based.  Moreover, changing focus
  > may change the index of multiple repeats that are nested, so one's spidey
  > sense gets the tingle of another optimization.
  > 
  > But the problem is that I cannot find any language in the XForms spec that
  > even implies a connection between repeat index changes and automatic
  > rebuilding.  For the record, I think the connection between repeat index
  > and rebuild is wrong, and I was going to write a last call comment to
  > suggest its removal.  But alas I have been foiled by the fact that it
  > already doesn't seem to exist in the spec.  If someone can find this,
  > please let me know; otherwise I will proceed on the assumption that the
  > spec does not follow a repeat index change with an automatic rebuild.
  > 
  > I believe that the original discussion about automatically rebuilding on
  > index change was held, at least in part, from a desire to correct for the
  > fact that index() *could be* invoked from the XPaths within an XForms bind
  > (i.e. from model binding expressions).
  > 
  > However, since such automatic rebuild is ultimately doomed to failure
  > (because of automatic index changes on focus change in 9.3.8), it seems
  > better to consider restricting the index() function to only being used in
  > certain cases.  Clearly, the index() function was designed for use in the
  > XPaths of XForms actions.  When index() is used in a UI binding, it is
  > possible though somewhat difficult to create problems due to the staleness
  > of the result.  More significant problems are easier to produce when
  > index() is used in a model binding expression.
  > 
  > In the past, this would have been hard, but XForms now requires different
  > exception behavior based on where an XPath is located. For example, in
  > Section 7.1, the choice of a binding exception versus a compute exception
  > is based on where the XPath is located.  An invocation of index()
  > appearing in any XPath other than those used in XForms actions should
  > either produce NaN or preferrably an appropriate exception.
  > 
  > 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
  > 
  > 

14.4 Section 9

PROBLEM ID: 118

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

NOTES:

  Some of the issues were mistakes on Aaron's part; others resulted in fixes.

ORIGINAL MESSAGE:

  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  
  31) Section 9.2.2 - no mention of the possible "value" attribute or its
  potential behavior as a child toggle.  Should at least be a nod to it.
  32) Section 9.2.3.1 - no schema change to show that @value is a possible
  attribute of case element.
  33) Section 9.3.1 - "if an element of the collection is non-relevant..."
  The 'if' starts the sentence but isn't capitalized.
  34) Section 9.3.1 - homogeneous collection example - the delete action
  should be handling a DOMActivate event, not an 'activate' event.
  35) Section 9.3.2 - how should we handle XML event handlers contained at
  root level under a repeat or a non-xforms element with repeat attrs?  Like
  itemset (listeners registered on the repeat rows and not on the repeat
  itself)?
  36) Section 9.3.3 - "An XForms processor must not allow XForms Actions
  contained by an itemset to handle events on the itemset."  It seems odd
  that an XForms action OUTSIDE the itemset can handle events on the itemset.
  And non-XForms actions in the itemset won't be repeated under the anonymous
  items.  For example, the xhtml or xml events 'handler' element would be
  nice to have repeated to allow the form author to handle xforms-select and
  xforms-deselect events with script.
  37) Section 9.3.5 - if we are inserting attributes, why does the order
  matter?  I didn't think that attribute order was guaranteed to be honored
  in DOM.
  38) Section 9.3.5 - the example with the repeat - there needs to be @id="R"
  on the repeat or the example won't work since the xf:insert uses the
  index() XPath extension function.
  39) Section 9.3.7 - "if the index evaluates to NaN the action has no
  effect."  The 'if' starts the sentence but isn't capitalized.
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  This is a response to several issues you raised in your last call comment email
  dated April 30.  Two of the issues in the sequence 31-39 have been flagged as
  separate issues, but I listed them below so you would know they weren't skippped
  accidentally.  Please let us know if you have any further concerns about the
  other issues that are addressed below.
  
  You can see the results of the fixes in the editor's copy of the spec available
  from the Forms WG website.
  
  Thanks,
  John Boyer
  
  31) Section 9.2.2 - no mention of the possible "value" attribute or its
  potential behavior as a child toggle.  Should at least be a nod to it.
  
  Yes.  This is because the case element child of switch (defined in 9.2.2)
  does not have a value attribute.
  
  Section 9.2.3.1 defines the case element child of toggle, which is a 
  completely separate element.  It has the same tag name, but a different
  parent.  That is the case element that supports the value attribute
  (and not the selected attribute).
  
  
  32) Section 9.2.3.1 - no schema change to show that @value is a possible
  attribute of case element.
  
  The schema will be changed.  
  
  33) Section 9.3.1 - "if an element of the collection is non-relevant..."
  The 'if' starts the sentence but isn't capitalized.
  
  Fixed. Not diff-marked.
  
  34) Section 9.3.1 - homogeneous collection example - the delete action
  should be handling a DOMActivate event, not an 'activate' event.
  
  Fixed, not diff-marked.
  
  35) Section 9.3.2 - how should we handle XML event handlers contained at
  root level under a repeat or a non-xforms element with repeat attrs?  Like
  itemset (listeners registered on the repeat rows and not on the repeat
  itself)?
  
  This has been filed as a separate issue and will be answered later.
  
  36) Section 9.3.3 - "An XForms processor must not allow XForms Actions
  contained by an itemset to handle events on the itemset."  It seems odd
  that an XForms action OUTSIDE the itemset can handle events on the itemset.
  And non-XForms actions in the itemset won't be repeated under the anonymous
  items.  For example, the xhtml or xml events 'handler' element would be
  nice to have repeated to allow the form author to handle xforms-select and
  xforms-deselect events with script.
  
  This has been filed as a separate issue and will be answered later.
  
  37) Section 9.3.5 - if we are inserting attributes, why does the order
  matter?  I didn't think that attribute order was guaranteed to be honored
  in DOM.
  
  Fixed. Diff-marked.  For attributes, we define the target location as the
  full attribute axis, so that the insertion does not specify where the new
  attribute nodes will go.  We believe Xpath supports identifying an attribute
  by position at a moment in time, but we agree that it may not be possible
  for an implementation to guarantee the positioning across a mutation of the
  data model.
  
  38) Section 9.3.5 - the example with the repeat - there needs to be @id="R"
  on the repeat or the example won't work since the xf:insert uses the
  index() XPath extension function.
  
  Fixed. Not diff-marked.
  
  39) Section 9.3.7 - "if the index evaluates to NaN the action has no
  effect."  The 'if' starts the sentence but isn't capitalized.
  
  Fixed. Not diff-marked.
  

14.5 LC: Legacy cruft in Section 9.3.8

PROBLEM ID: 23

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

ORIGINAL MESSAGE:

  From: "John Boyer" <boyerj@ca.ibm.com>
  
  The following paragraph in section 9.3.8 should be removed:
  
  The binding expression attached to the repeating sequence returns a
  node-set of the collection being populated, not an individual node. Within
  the body of element repeat, binding expressions are evaluated with a
  context node of the node determined by the index. Repeat processing uses
  XPath expressions to address the collection over which element repeat
  operates.
  
  The first and third sentences are obvious given other material in Section
  9, and the second sentence is old and wrong, contradicting the copious
  material in Section 7.4 on evaluation context (see esp. point 2c and 2d in
  7.4).
  
  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>
  
  The working group agreed to the removal of the paragraph.
  
  > The following paragraph in section 9.3.8 should be removed:
  > 
  > The binding expression attached to the repeating sequence returns a
  > node-set of the collection being populated, not an individual node. Within
  > the body of element repeat, binding expressions are evaluated with a
  > context node of the node determined by the index. Repeat processing uses
  > XPath expressions to address the collection over which element repeat
  > operates.
  > 
  > The first and third sentences are obvious given other material in Section
  > 9, and the second sentence is old and wrong, contradicting the copious
  > material in Section 7.4 on evaluation context (see esp. point 2c and 2d in
  > 7.4).
  > 
  > 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
  > 
  > 

14.6 Request for an update for <repeat/> element.

PROBLEM ID: 26

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

NOTES:

  As explained in another LC comment, this is substantive in that it changes
  behavior of the nodeset binding of repeat, but we expect no objection as the WG
  is unanimously in favor of this and indeed most implementers of 1.0 do not
  observe the homogeneous collection limitation (which 1.0 left 'undefined' to
  allow implementers to try it out). This changes is also consisten with the
  generalizations made to insert and delete actions.

ORIGINAL MESSAGE:

  From: "Ivan Latysh" <IvanLatysh@yahoo.ca>
  
  
  Hello All,
  
     As we discussed on www-forms@w3.org mailing list, <repeat/> element has  
  restrictions on node-set that it can
     operate with, since such limitation has been made to simplify insert and  
  delete elements and now insert and delete can
     operate with arbitrary node-sets I propose to lift such restriction from  
  <repeat/> element and make it work with
     arbitrary node-set as insert and delete do.
  
  -- 
  Best regards,
    Ivan                          mailto:IvanLatysh@yahoo.ca
  

FOLLOWUP 1:

  From: Mail Delivery Subsystem <MAILER-DAEMON@aptest.com>
  
  This is a MIME-encapsulated message
  
  --l5DHSOco003364.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:26:57 -0500
  from htmlwg.mn.aptest.com [127.0.0.1]
  
     ----- Transcript of session follows -----
  451 4.4.1 reply: read error from a.mx.mail.yahoo.com.
  ... while talking to g.mx.mail.yahoo.com.:
  <<< 421 Message from (208.42.66.11) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
  ... while talking to d.mx.mail.yahoo.com.:
  >>> DATA
  <<< 451 Message temporarily deferred - [70]
  ... while talking to b.mx.mail.yahoo.com.:
  <<< 421 Message from (208.42.66.11) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
  ... while talking to c.mx.mail.yahoo.com.:
  >>> QUIT
  <<< 421 Message from (208.42.66.11) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
  ... while talking to e.mx.mail.yahoo.com.:
  >>> DATA
  <<< 421 Message temporarily deferred - 4.16.51. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
  <IvanLatysh@yahoo.ca>... Deferred
  Warning: message still undelivered after 4 hours
  Will keep trying until message is 5 days old
  
  --l5DHSOco003364.1181756668/htmlwg.mn.aptest.com
  Content-Type: message/delivery-status
  
  Reporting-MTA: dns; htmlwg.mn.aptest.com
  Arrival-Date: Wed, 13 Jun 2007 08:26:57 -0500
  
  Final-Recipient: RFC822; IvanLatysh@yahoo.ca
  Action: delayed
  Status: 4.4.2
  Remote-MTA: DNS; e.mx.mail.yahoo.com
  Last-Attempt-Date: Wed, 13 Jun 2007 12:44:28 -0500
  Will-Retry-Until: Mon, 18 Jun 2007 08:26:57 -0500
  
  --l5DHSOco003364.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 l5DDQvrF001703
  	for <IvanLatysh@yahoo.ca>; Wed, 13 Jun 2007 08:26:57 -0500
  Date: Wed, 13 Jun 2007 08:26:57 -0500
  Message-Id: <200706131326.l5DDQvrF001703@htmlwg.mn.aptest.com>
  From: xforms-issues@mn.aptest.com
  To: IvanLatysh@yahoo.ca
  Subject: Re: Request for an update for <repeat/> element. (PR#26)
  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=26     
  
  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
  
  
  --l5DHSOco003364.1181756668/htmlwg.mn.aptest.com--
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Ivan,
  
  The working group agreed that the "homogeneous collection" language in "repeat"
  was no longer necessary, so the restriction has been removed. Please see the
  latest editor's draft available from the working group home page and via this
  link:
  
  http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html
  
  We trust that this change is satisfactory to you.  Please let us know if you
  have any further concerns about this issue.
  
  Best regards,
  John Boyer
  
  > 
  > Hello All,
  > 
  >    As we discussed on www-forms@w3.org mailing list, <repeat/> element has  
  > restrictions on node-set that it can
  >    operate with, since such limitation has been made to simplify insert and  
  > delete elements and now insert and delete can
  >    operate with arbitrary node-sets I propose to lift such restriction from  
  > <repeat/> element and make it work with
  >    arbitrary node-set as insert and delete do.
  > 
  > -- 
  > Best regards,
  >   Ivan                          mailto:IvanLatysh@yahoo.ca
  > 
  > 

14.7 Section 9

PROBLEM ID: 153

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

NOTES:

  Spec ready solutions are now available for both of these issues in the editor's
  draft.
  
  35) We clarified in a note that all template content (including actions) are
  made
  unavailable to the host language processor.  So handlers declared within a
  repeat do not handle elements dispatched to the repeat (and likewise for
  itemset).  Actions declared within a repeat template operate over the repeated
  content (e.g. the item elements generated by an itemset).
  
  36) The actions within an itemset *are* applicable to each item generated.  The
  sentence claiming that actions in the itemset don't handle events on
  the itemset has been changed to simply state that, as with repeat, handlers
  defined
  within itemset do not handle events on the itemset.
  
  This is necessary to prevent a double run of event handlers as events bubble up
  from generated content to the generating repeat or itemset.
  
  An example of how to handle events dispatched to a repeat or itemset was added.

ORIGINAL MESSAGE:

  From: aaronr@us.ibm.com
  
  Full_Name: Aaron Reed
  Submission from: (NULL) (32.97.110.142)
  Submitted by: boyerj
  
  
  35) Section 9.3.2 - how should we handle XML event handlers contained at
  root level under a repeat or a non-xforms element with repeat attrs?  Like
  itemset (listeners registered on the repeat rows and not on the repeat
  itself)?
  
  36) Section 9.3.3 - "An XForms processor must not allow XForms Actions
  contained by an itemset to handle events on the itemset."  It seems odd
  that an XForms action OUTSIDE the itemset can handle events on the itemset.
  And non-XForms actions in the itemset won't be repeated under the anonymous
  items.  For example, the xhtml or xml events 'handler' element would be
  nice to have repeated to allow the form author to handle xforms-select and
  xforms-deselect events with script.
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  Spec ready solutions are now available for both of these issues in the editor's
  draft. [1] (9.3.3 Repeat Processing and 9.3.6 The itemset Element)
  
  35) We clarified in a note that all template content (including actions) are
  made
  unavailable to the host language processor.  So handlers declared within a
  repeat do not handle elements dispatched to the repeat (and likewise for
  itemset).  Actions declared within a repeat template operate over the repeated
  content (e.g. the item elements generated by an itemset).
  
  36) The actions within an itemset *are* applicable to each item generated.  The
  sentence claiming that actions in the itemset don't handle events on
  the itemset has been changed to simply state that, as with repeat, handlers
  defined
  within itemset do not handle events on the itemset.
  
  This is necessary to prevent a double run of event handlers as events bubble up
  from generated content to the generating repeat or itemset.
  
  An example of how to handle events dispatched to a repeat or itemset was added.
  
  Regards,
  
  Nick Van den Bleeken
  [1] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-repeat-module
  
  > Full_Name: Aaron Reed
  > Submission from: (NULL) (32.97.110.142)
  > Submitted by: boyerj
  > 
  > 
  > 35) Section 9.3.2 - how should we handle XML event handlers contained at
  > root level under a repeat or a non-xforms element with repeat attrs?  Like
  > itemset (listeners registered on the repeat rows and not on the repeat
  > itself)?
  > 
  > 36) Section 9.3.3 - "An XForms processor must not allow XForms Actions
  > contained by an itemset to handle events on the itemset."  It seems odd
  > that an XForms action OUTSIDE the itemset can handle events on the itemset.
  > And non-XForms actions in the itemset won't be repeated under the anonymous
  > items.  For example, the xhtml or xml events 'handler' element would be
  > nice to have repeated to allow the form author to handle xforms-select and
  > xforms-deselect events with script.
  > 
  > 

15. XPath

15.1 7.6

PROBLEM ID: 143

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

NOTES:

  With regard to specific functions like boolean-from-string(), many were already
  defined by XForms 1.0 a very long time ago because, in XPath 1.0, the boolean()
  function does not do the right thing.
  
  With regard to the more general suggestion of putting our functions into the
  XForms namespace and then providing a way to switch to that namespace as the
  default, unfortunately we do not believe this is implementable with XPath 1.0
  evaluators.
  
  Therefore the working group defers putting its functions into the XForms
  namespace until XForms 2.0 when we expect XPath 2.0 to be adopted.

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
  
      H. Clearly there is a need to provide backwards compatibility with
      XForms 1.0 in the set of additional functions provided. (It's a
      shame that these weren't defined to be in their own
      namespace). However, we would also like to see some kind of
      migration strategy that moves users forward to the XPath 2.0
      replacements for these functions where these exist. For example,
      xs:boolean() in XPath 2.0 is identical to boolean-from-string() in
      XForms.  (On a point of detail, the values "true" and "false" in
      XML Schema are case-sensitive whereas this function is described as
      case-insensitive).
  
      A possible migration strategy might start by putting these
      functions in a separate namespace, and giving users some way to
      select the function namespaces they want to use in their
      application.
  
      We have not actually checked how many of the additional functions were
      already defined in XForms 1.0.
  
  
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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 Michael,
  
  With regard to specific functions like boolean-from-string(), many were already
  defined by XForms 1.0 a very long time ago because, in XPath 1.0, the boolean()
  function does not do the right thing.
  
  With regard to the more general suggestion of putting our functions into the
  XForms namespace and then providing a way to switch to that namespace as the
  default, unfortunately we do not believe this is implementable with XPath 1.0
  evaluators.
  
  Therefore the working group defers putting its functions into the XForms
  namespace until XForms 2.0 when we expect XPath 2.0 to be adopted.
  
  Best regards,
  John Boyer
  
  > 
  > 
  > 
  >     H. Clearly there is a need to provide backwards compatibility with
  >     XForms 1.0 in the set of additional functions provided. (It's a
  >     shame that these weren't defined to be in their own
  >     namespace). However, we would also like to see some kind of
  >     migration strategy that moves users forward to the XPath 2.0
  >     replacements for these functions where these exist. For example,
  >     xs:boolean() in XPath 2.0 is identical to boolean-from-string() in
  >     XForms.  (On a point of detail, the values "true" and "false" in
  >     XML Schema are case-sensitive whereas this function is described as
  >     case-insensitive).
  > 
  >     A possible migration strategy might start by putting these
  >     functions in a separate namespace, and giving users some way to
  >     select the function namespaces they want to use in their
  >     application.
  > 
  >     We have not actually checked how many of the additional functions were
  >     already defined in XForms 1.0.
  > 
  > 
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  With regard to specific functions like boolean-from-string(), many were already
  defined by XForms 1.0 a very long time ago because, in XPath 1.0, the boolean()
  function does not do the right thing.
  
  With regard to the more general suggestion of putting our functions into the
  XForms namespace and then providing a way to switch to that namespace as the
  default, unfortunately we do not believe this is implementable with XPath 1.0
  evaluators.
  
  Therefore the working group defers putting its functions into the XForms
  namespace until XForms 2.0 when we expect XPath 2.0 to be adopted.
  
  Best regards,
  John Boyer
  
  > 
  > 
  > 
  >     H. Clearly there is a need to provide backwards compatibility with
  >     XForms 1.0 in the set of additional functions provided. (It's a
  >     shame that these weren't defined to be in their own
  >     namespace). However, we would also like to see some kind of
  >     migration strategy that moves users forward to the XPath 2.0
  >     replacements for these functions where these exist. For example,
  >     xs:boolean() in XPath 2.0 is identical to boolean-from-string() in
  >     XForms.  (On a point of detail, the values "true" and "false" in
  >     XML Schema are case-sensitive whereas this function is described as
  >     case-insensitive).
  > 
  >     A possible migration strategy might start by putting these
  >     functions in a separate namespace, and giving users some way to
  >     select the function namespaces they want to use in their
  >     application.
  > 
  >     We have not actually checked how many of the additional functions were
  >     already defined in XForms 1.0.
  > 
  > 
  > 
  > 

15.2 Comments on XPath 2.0 features

PROBLEM ID: 107

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

ORIGINAL MESSAGE:

  From: "Jurgis Lukss" <jlukss@gmail.com>
  
  
  
  Hello,
  
  By using last chance to send my comments on XForms working draft, I wanted
  to clarify following issue. I'm using XForms for at least the last two
  quarters of a year in our projects and numerous times I have been saved by
  following XPath 2.0 feature:
  http://www.w3.org/TR/xpath20/#id-for-expressions
  
  I believe this is only way to bind two parallel nodeset tree's children.
  For
  example:
  If I have following XML structure:
  
  <rootnode>
  <nodeset1>
  <element_type_1 id="1">value 1</element_type_1>
  <element_type_1 id="2">value 2</element_type_1>
  </nodeset1>
  <nodeset2>
  <element_type_2 ref_id="1" />
  <element_type_2 ref_id="2" />
  </nodeset2>
  </rootnode>
  
  
  Now, if I want output value of element_type_2 and value of element_type_1
  with matching @ref_id=@id using xforms:repeat and xforms:output. I could
  find only one solution:
  
  <xforms:repeat ref="/rootnode/nodeset2/element_type_2">
  <xforms:output value="." />
  <xforms:output value="for $el_id in ./@ref_id return
  (/rootnode/nodeset1/element_type_1[@id=$el_id])" />
  </xforms:repeat>
  
  I believe that this will be a common problem if XForms were to be used more
  often and by many more developers. And it would be worth considering
  including at least this functionality, if not whole XPath 2.0, in
  XForms 1.1recommendation. But if there is any other or even a trivial
  solution to this
  problem, then it should be included as an example.
  
  
  - Jurgis Lukss
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Jurgis,
  
  XPath 2.0 features, though valuable, are not in scope of the XForms 1.1
  requirements, so we accept this as for XForms 1.2 future features.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Form WG
  
  > Hello,
  > 
  > By using last chance to send my comments on XForms working draft, I wanted
  > to clarify following issue. I'm using XForms for at least the last two
  > quarters of a year in our projects and numerous times I have been saved by
  > following XPath 2.0 feature:
  > http://www.w3.org/TR/xpath20/#id-for-expressions
  > 
  > I believe this is only way to bind two parallel nodeset tree's children.
  > For
  > example:
  > If I have following XML structure:
  > 
  > <rootnode>
  > <nodeset1>
  > <element_type_1 id="1">value 1</element_type_1>
  > <element_type_1 id="2">value 2</element_type_1>
  > </nodeset1>
  > <nodeset2>
  > <element_type_2 ref_id="1" />
  > <element_type_2 ref_id="2" />
  > </nodeset2>
  > </rootnode>
  > 
  > 
  > Now, if I want output value of element_type_2 and value of element_type_1
  > with matching @ref_id=@id using xforms:repeat and xforms:output. I could
  > find only one solution:
  > 
  > <xforms:repeat ref="/rootnode/nodeset2/element_type_2">
  > <xforms:output value="." />
  > <xforms:output value="for $el_id in ./@ref_id return
  > (/rootnode/nodeset1/element_type_1[@id=$el_id])" />
  > </xforms:repeat>
  > 
  > I believe that this will be a common problem if XForms were to be used more
  > often and by many more developers. And it would be worth considering
  > including at least this functionality, if not whole XPath 2.0, in
  > XForms 1.1recommendation. But if there is any other or even a trivial
  > solution to this
  > problem, then it should be included as an example.
  > 
  > 
  > - Jurgis Lukss
  > 
  > 

15.3 [LC: editorial] 7.11.3 The choose() Function

PROBLEM ID: 71

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

NOTES:

  See reply.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#fn-choose
  
  Please explain that this is a variant of if() that returns objects
  rather than strings.
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Dear Steven,
  
  The working group agreed to modify and accept this last call comment.  Due to
  anticipation of name conflict with the XPath 2.0 'if' construct once XForms
  migrates to XPath 2.0, it was deemed necessary to deprecate if() and encourage
  use of choose() in the future.
  
  Still the relationship between choose() and if(), along with which one is most
  appropriate to use, has been clarified, which we believe was the intent of this
  LC comment. Please see the editor's draft available from the working group home
  page and specifically Section 7.10.1.
  
  Thank you, 
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#fn-choose
  > 
  > Please explain that this is a variant of if() that returns objects
  > rather than strings.
  > 
  > 

15.4 7.11.4

PROBLEM ID: 149

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

NOTES:

  The working group decided to add the two parameter id() function, call it id(),
  and make its semantics as close to XPath 2.0 as possible.
  
  Any semantic differences remaining will need to be addressed in XForms 2.0 when
  we migrate to XPath 2.0.

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
      N. The two-argument id() function poses particular problems because
      its semantics are very similar but not identical to the
      two-argument id() function in XPath 2.0
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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 Michael,
  
  The working group decided to add the two parameter id() function, call it id(),
  and make its semantics as close to XPath 2.0 as possible.
  
  Any semantic differences remaining will need to be addressed in XForms 2.0 when
  we migrate to XPath 2.0.
  
  Regards,
  
  Nick Van den Bleeken
  
  
  >     N. The two-argument id() function poses particular problems because
  >     its semantics are very similar but not identical to the
  >     two-argument id() function in XPath 2.0
  > 
  > 
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  The working group decided to add the two parameter id() function, call it id(),
  and make its semantics as close to XPath 2.0 as possible.
  
  Any semantic differences remaining will need to be addressed in XForms 2.0 when
  we migrate to XPath 2.0.
  
  Regards,
  
  Nick Van den Bleeken
  
  
  >     N. The two-argument id() function poses particular problems because
  >     its semantics are very similar but not identical to the
  >     two-argument id() function in XPath 2.0
  > 
  > 

15.5 [LC: editorial] 7.10.1 The now() Function

PROBLEM ID: 65

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

NOTES:

  Process the following issues together : XPath/11, XPath/12, XPath/69, XPath/63
  
  Steven was in the room and agreed.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#fn-now
  
  Please give examples
  

15.6 Things wrong with section "7.5 Binding Expressions" and related

PROBLEM ID: 41

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

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  This is a follow-up to the thread on using index() in UI bindings [1]
  that focuses on issues with binding expressions in the spec.
  
  I already pointed out that section 7.5.1 is broken [2] (private link),
  and the XSL and XQuery Working Group has some releated LC comment on
  this as well [3].
  
  Here are some further thoughs:
  
  1. Intro to 7.5 says:
  
        "By default, all binding expressions refer to the first instance
         within the context model. This behavior can be changed with the
         instance() function."
  
      Is this still the right place for this sentence? This is noise I
      think since we have an improved section "7.4 Evaluation Context".
  
      I would recommend removing that sentence and possibly point to 7.4.
  
  2. Section "7.5.1 Dynamic Dependencies"
  
       This section needs to be entirely rewritten IMO. In addition to the
       points raised in [2] and [3]:
  
       * "In particular, there are restrictions on model binding
         expressions that create dynamic dependencies [...]". This
         concerns Model Binding Expressions so should be removed, or
         rewritten and integrated into "7.5.2 Model Binding Expressions".
  
       I think that 7.5.1 must simply contain a clearer definition of a
       dynamic dependency, a rationale for the distinction, and at least
       one example (could be part of the rationale).
  
  3. Section "7.5.2 Model Binding Expressions"
  
       Is any XPath expression on xforms:bind a Model Binding Expressions?
       I thought only @nodeset expressions were called Model Binding
       Expressions but I seem to be wrong. If not, then @calculate,
       @constraint, are also MBEs?
  
       This is surprising because section ".5.4 The
       xforms-compute-exception Event" says:
  
       "an error occurring during XPath evaluation for a model item
        property"
  
       And section "7.6 The XForms Function Library" also mentions
       something along these lines.
  
       So binding expressions do not necessarly throw binding exceptions?
       This sounds incoherent. Maybe the confusion stems from the fact
       that "binding expression" can be interpreted either as "an
       expression that binds", i.e. on @ref or @nodeset, but also as "an
       expression on xforms:bind".
  
       I think all this needs to be clarified. As mentioned in a separate
       LC comment [4], there seems to be a general lack of clarity about
       binding and compute exceptions.
  
  4. Section "7.5.3 UI Binding Expressions":
  
       "Dynamic dependences are allowed in UI binding expressions based on
        the conformance profile."
  
       I have no idea what the second part of the sentence means. The term
       "conformance profile" occurs only twice in the whole spec, and is
       not defined AFAICT. "XForms Full" is defined as a "conformance
       level", not as a "conformance profile".
  
       Furthermore, even with a definition, "based on the conformance
       profile" is way too vague. If supporting dynamic dependencies is a
       feature optional in certain profiles, we can say that. However,
       section "12.4.2 XForms Full" does not mention that XForms Full must
       support dynamic dependencies.
  
       This section should also precise the notion of dependency for UI
       bindings. In [1] John mentions that:
  
       "dependencies are established based on references to nodes of
        instance data (in 4.3.6)."
  
       But 4.3.6 regards only xforms-recalculate, and it is not clear that
       it applies to UI bindings.
  
  5. Section "4.3.4 The xforms-refresh Event":
  
       "3. All UI bindings should be reevaluated as necessary."
  
       "as necessary" needs to be made (much) clearer.
  
  6. Section "4.6.7 Sequence: Value Change":
  
       "xforms-refresh performs reevaluation of UI binding expressions"
  
       This would be where "as necessary" would be less out of place ;-)
  
  -Erik
  
  [1] http://lists.w3.org/Archives/Public/public-forms/2007May/0008.html
  [2] http://lists.w3.org/Archives/Member/w3c-forms/2007JanMar/0053.html
  [3] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0052.html
  [4] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0059.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 accepted all of your points as issues needing work.  In
  particular, notions of dynamic dependency and model binding expression were
  rigorously defined.  The results are now available in the editor's draft at
  http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html
  
  Please let us know if you have any further concerns about these issues.
  
  Thank you,
  John Boyer
  
  > 
  > All,
  > 
  > This is a follow-up to the thread on using index() in UI bindings [1]
  > that focuses on issues with binding expressions in the spec.
  > 
  > I already pointed out that section 7.5.1 is broken [2] (private link),
  > and the XSL and XQuery Working Group has some releated LC comment on
  > this as well [3].
  > 
  > Here are some further thoughs:
  > 
  > 1. Intro to 7.5 says:
  > 
  >       "By default, all binding expressions refer to the first instance
  >        within the context model. This behavior can be changed with the
  >        instance() function."
  > 
  >     Is this still the right place for this sentence? This is noise I
  >     think since we have an improved section "7.4 Evaluation Context".
  > 
  >     I would recommend removing that sentence and possibly point to 7.4.
  > 
  > 2. Section "7.5.1 Dynamic Dependencies"
  > 
  >      This section needs to be entirely rewritten IMO. In addition to the
  >      points raised in [2] and [3]:
  > 
  >      * "In particular, there are restrictions on model binding
  >        expressions that create dynamic dependencies [...]". This
  >        concerns Model Binding Expressions so should be removed, or
  >        rewritten and integrated into "7.5.2 Model Binding Expressions".
  > 
  >      I think that 7.5.1 must simply contain a clearer definition of a
  >      dynamic dependency, a rationale for the distinction, and at least
  >      one example (could be part of the rationale).
  > 
  > 3. Section "7.5.2 Model Binding Expressions"
  > 
  >      Is any XPath expression on xforms:bind a Model Binding Expressions?
  >      I thought only @nodeset expressions were called Model Binding
  >      Expressions but I seem to be wrong. If not, then @calculate,
  >      @constraint, are also MBEs?
  > 
  >      This is surprising because section ".5.4 The
  >      xforms-compute-exception Event" says:
  > 
  >      "an error occurring during XPath evaluation for a model item
  >       property"
  > 
  >      And section "7.6 The XForms Function Library" also mentions
  >      something along these lines.
  > 
  >      So binding expressions do not necessarly throw binding exceptions?
  >      This sounds incoherent. Maybe the confusion stems from the fact
  >      that "binding expression" can be interpreted either as "an
  >      expression that binds", i.e. on @ref or @nodeset, but also as "an
  >      expression on xforms:bind".
  > 
  >      I think all this needs to be clarified. As mentioned in a separate
  >      LC comment [4], there seems to be a general lack of clarity about
  >      binding and compute exceptions.
  > 
  > 4. Section "7.5.3 UI Binding Expressions":
  > 
  >      "Dynamic dependences are allowed in UI binding expressions based on
  >       the conformance profile."
  > 
  >      I have no idea what the second part of the sentence means. The term
  >      "conformance profile" occurs only twice in the whole spec, and is
  >      not defined AFAICT. "XForms Full" is defined as a "conformance
  >      level", not as a "conformance profile".
  > 
  >      Furthermore, even with a definition, "based on the conformance
  >      profile" is way too vague. If supporting dynamic dependencies is a
  >      feature optional in certain profiles, we can say that. However,
  >      section "12.4.2 XForms Full" does not mention that XForms Full must
  >      support dynamic dependencies.
  > 
  >      This section should also precise the notion of dependency for UI
  >      bindings. In [1] John mentions that:
  > 
  >      "dependencies are established based on references to nodes of
  >       instance data (in 4.3.6)."
  > 
  >      But 4.3.6 regards only xforms-recalculate, and it is not clear that
  >      it applies to UI bindings.
  > 
  > 5. Section "4.3.4 The xforms-refresh Event":
  > 
  >      "3. All UI bindings should be reevaluated as necessary."
  > 
  >      "as necessary" needs to be made (much) clearer.
  > 
  > 6. Section "4.6.7 Sequence: Value Change":
  > 
  >      "xforms-refresh performs reevaluation of UI binding expressions"
  > 
  >      This would be where "as necessary" would be less out of place ;-)
  > 
  > -Erik
  > 
  > [1] http://lists.w3.org/Archives/Public/public-forms/2007May/0008.html
  > [2] http://lists.w3.org/Archives/Member/w3c-forms/2007JanMar/0053.html
  > [3] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0052.html
  > [4] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0059.html
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

REPLY 2:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  We will defer the adoption of XPath 2.0 until a later version (probably XForms
  2.0) due to reasons we mentioned in an earlier reply. Therefore we can't use the
  XPath 2.0 description of evaluation context.
  
  Moreover the evaluation context section (now 7.2) is also very precisely
  tailored to our needs based on XPath 1.0, which we must use for XForms 1.1.  It
  also accounts for content repetition that XForms performs, which is why the
  section contains more information than what might be described for the
  evaluation context of a single XPath expression.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  >     F. The XPath 2.0 specification provides a much more formal and
  >     comprehensive description of the evaluation context, which would
  >     provide a more solid basis for this part of the specification.
  >     (: You could use this as a guide even for XPath 1.0 :)
  > 
  > 

15.7 [LC] 7.10.6 The local-date() Function and 7.10.7 The local-dateTime() Function

PROBLEM ID: 69

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

NOTES:

  RESOLUTION: Clarify and add examples to show that now() returns Z time only and
  add examples of local-dateTime() that connect it to now() return results
  
  Examples, OK.  The difference is basically whether or not the returned value is
  just the local date or date/time or whether it is corrected from the local
  value
  to the UTC value (which is what now() does).
  
  An example showing late in the day pacific time returning early the next day
  UTC
  from now() should suffice.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#fn-local-date
  http://www.w3.org/TR/xforms11/#fn-local-dateTime
  
  I don't understand the difference between these and the function now().
  
  Please give examples along the lines of "if now() returns "...." then
  local-DateTime would return "...""
  

FOLLOWUP 1:

  From: "Steven Pemberton" <steven.pemberton@cwi.nl>
  
  > Steven,
  >
  > We will add examples to show that now() returns Z time only
  
  Just for the record, I think this is a bad idea. I understand (now) that  
  the current text for now() is ambiguous, but I believe the wrong  
  interpretation had been chosen to solve that ambiguity. Either way some  
  implementations will have to change, so I think changes should be chosen  
  on what is best for authors, and I believe that most authors will expect  
  now() to return the local time (not UTC), amongst other reasons because  
  that is what spreadsheets return for the function now().
  
  I do however agree there is a use case for a function that returns UTC.
  
  Best wishes,
  
  Steven Pemberton
  
    and add
  > examples of
  > local-dateTime() showing that the returned result is in the local  
  > timezone.
  >
  > The difference between now() and local-dateTime() is basically whether  
  > or not
  > the returned value is just in the zulu timezone or the local timezone.
  >
  > Regards,
  >
  > Nick Van den Bleeken
  >
  >>
  >> http://www.w3.org/TR/xforms11/#fn-local-date
  >> http://www.w3.org/TR/xforms11/#fn-local-dateTime
  >>
  >> I don't understand the difference between these and the function now().
  >>
  >> Please give examples along the lines of "if now() returns "...." then
  >> local-DateTime would return "...""
  >>
  >>
  
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Steven,
  
  We will add examples to show that now() returns Z time only and add examples of
  local-dateTime() showing that the returned result is in the local timezone.
  
  The difference between now() and local-dateTime() is basically whether or not
  the returned value is just in the zulu timezone or the local timezone.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > http://www.w3.org/TR/xforms11/#fn-local-date
  > http://www.w3.org/TR/xforms11/#fn-local-dateTime
  > 
  > I don't understand the difference between these and the function now().
  > 
  > Please give examples along the lines of "if now() returns "...." then
  > local-DateTime would return "...""
  > 
  > 

15.8 [LC] 7.9.4 The digest() Function

PROBLEM ID: 68

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

NOTES:

  This is only substantive in the sense that there are fewer keywords available
  for the parameters, but all possible features are still accessible by the
  reduced number of keywords.
  
  1)drop alternatives of lower case keywords (e.g.: drop sha-256, SHA256, SHA-256
  variants of sha256)
  
  2) editorial correct function names in samples
  
  process together with XPath/67

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#fn-digest
  
  Why bother with all the alternatives for the parameter? Why not just
  md5/sha1/sha256/sha384/sha512
  
  In the examples the function has the wrong name.
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The working group reduced the number of alternatives to one per hash algorithm
  as requested.  The only difference is that the keywords chosen were based on the
  algorithm names as given in their specifications: MD5, SHA-1, SHA-256, SHA-384
  and SH-512.
  The examples were also corrected.
  
  Thanks,
  John Boyer
  > 
  > http://www.w3.org/TR/xforms11/#fn-digest
  > 
  > Why bother with all the alternatives for the parameter? Why not just
  > md5/sha1/sha256/sha384/sha512
  > 
  > In the examples the function has the wrong name.
  > 
  > 

15.9 7.9.3

PROBLEM ID: 146

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

NOTES:

  This is a substantive change for which we do not anticipate an objection because
  the functions were technically unimplementable (as described below) and because
  they were only exposed because they seemed like they might be useful utilities
  that would be available based on parts of functionality needed by digest() and
  hmac().  No requirements go unsatisfied by their removal.
  
  RESOLUTION: We will shoot both decode and encode because :
  
  1) XPath can't store control characters in a string
  http://www.w3.org/TR/xpath#strings
  2) encode and decode work on bytes in other languages ( most of the people will
  expect that encode(decode(<data>)) returns the same string, but this is
  not the
  case because control characters aren't allowed, and if we use the 32-bit string
  characters the string will double, going through UTF-8 also modifies the binary
  data

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
      K. The decode() function needs to define an additional error, for
      the case where the data can be decoded as a UTF-8 character string
      but that string contains a character not allowed in XML.
  
      The name of the encode() function is much too generic, and should
      be renamed to something that indicates its purpose more clearly. In
      the description of the encode() function, "The data string is
      serialized as UTF-8" is ambiguous - it might mean (a) the parameter
      must be UTF-8, or (b) the function serializes the input string as
      UTF-8.
  
      Also, UTF-8 is hard-coded. There are other possibilities.
  
      The phrase "string of data" is redundant; you can simply say
      "string".
  
      In XPath 2.0, you would probably want to have two functions - one
      would return the base64 binary representation, the other would
      return the hex binary representation. Conversion of the binary to a
      string would be done by the string() function.
  
      These two functions are candidates for incorporating into XPath 2.N
      core. We would be interested in working with you on the design of
      these two functions.
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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 Michael,
  
  The working group solved this issue indirectly.  We found it necessary to remove
  the functions encode() and decode().  Although they seem like they could be
  useful, the decode function can produce results that do not fit the XPath data
  model's restriction to XML Char, which means that encode() would need to take
  illegal string data in order to be fully functional.
  
  Best regards,
  John Boyer
  
  > 
  > 
  >     K. The decode() function needs to define an additional error, for
  >     the case where the data can be decoded as a UTF-8 character string
  >     but that string contains a character not allowed in XML.
  > 
  >     The name of the encode() function is much too generic, and should
  >     be renamed to something that indicates its purpose more clearly. In
  >     the description of the encode() function, "The data string is
  >     serialized as UTF-8" is ambiguous - it might mean (a) the parameter
  >     must be UTF-8, or (b) the function serializes the input string as
  >     UTF-8.
  > 
  >     Also, UTF-8 is hard-coded. There are other possibilities.
  > 
  >     The phrase "string of data" is redundant; you can simply say
  >     "string".
  > 
  >     In XPath 2.0, you would probably want to have two functions - one
  >     would return the base64 binary representation, the other would
  >     return the hex binary representation. Conversion of the binary to a
  >     string would be done by the string() function.
  > 
  >     These two functions are candidates for incorporating into XPath 2.N
  >     core. We would be interested in working with you on the design of
  >     these two functions.
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Michael,
  
  The working group solved this issue indirectly.  We found it necessary to remove
  the functions encode() and decode().  Although they seem like they could be
  useful, the decode function can produce results that do not fit the XPath data
  model's restriction to XML Char, which means that encode() would need to take
  illegal string data in order to be fully functional.
  
  Best regards,
  John Boyer
  
  > 
  > 
  >     K. The decode() function needs to define an additional error, for
  >     the case where the data can be decoded as a UTF-8 character string
  >     but that string contains a character not allowed in XML.
  > 
  >     The name of the encode() function is much too generic, and should
  >     be renamed to something that indicates its purpose more clearly. In
  >     the description of the encode() function, "The data string is
  >     serialized as UTF-8" is ambiguous - it might mean (a) the parameter
  >     must be UTF-8, or (b) the function serializes the input string as
  >     UTF-8.
  > 
  >     Also, UTF-8 is hard-coded. There are other possibilities.
  > 
  >     The phrase "string of data" is redundant; you can simply say
  >     "string".
  > 
  >     In XPath 2.0, you would probably want to have two functions - one
  >     would return the base64 binary representation, the other would
  >     return the hex binary representation. Conversion of the binary to a
  >     string would be done by the string() function.
  > 
  >     These two functions are candidates for incorporating into XPath 2.N
  >     core. We would be interested in working with you on the design of
  >     these two functions.
  > 
  > 

15.10 7.1

PROBLEM ID: 140

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

NOTES:

  This one says "Why not XPath 2.0 now in 1.1" which we already decided not to do
  until probably XForms 2.0 due to the huge ramifications on dependency
  calculations of things like XPath 2.0's 'if'
  
  But we did deprecate "if" and we removed the return type rationalization for
  choose(), so we have taken steps to smooth the way for XPath 2.0.

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
      E. "A future version of XForms is expected to use XPath 2.0". We
      think it would be more appropriate to use XPath 2.0 in the current
      version.
  
      Even if you choose not to use XPath 2.0 now, we think you should
      consider laying the groundwork for a transition to XPath 2.0 in the
      current version. (: We noted that there are a few areas where transition
      to 2.0 will cause some compatibility problems - some of these are noted
      below. In these areas in particular we think it would be useful if
      XForms 1.1 provided alternatives to the current 1.0 syntax in a way
      that eases transition to XPath 2.0 later :)
  
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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 Michael,
  
  We will defer the adoption of XPath 2.0 until a later version (probably XForms
  2.0) 
  due to the huge ramifications on dependency calculations of things like XPath
  2.0's 'if'
  
  But we did deprecate "if" and we removed the return type rationalization for
  choose(), so we have taken steps to smooth the way for XPath 2.0.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > 
  >     E. "A future version of XForms is expected to use XPath 2.0". We
  >     think it would be more appropriate to use XPath 2.0 in the current
  >     version.
  > 
  >     Even if you choose not to use XPath 2.0 now, we think you should
  >     consider laying the groundwork for a transition to XPath 2.0 in the
  >     current version. (: We noted that there are a few areas where transition
  >     to 2.0 will cause some compatibility problems - some of these are noted
  >     below. In these areas in particular we think it would be useful if
  >     XForms 1.1 provided alternatives to the current 1.0 syntax in a way
  >     that eases transition to XPath 2.0 later :)
  > 
  > 
  > 
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  We will defer the adoption of XPath 2.0 until a later version (probably XForms
  2.0) 
  due to the huge ramifications on dependency calculations of things like XPath
  2.0's 'if'
  
  But we did deprecate "if" and we removed the return type rationalization for
  choose(), so we have taken steps to smooth the way for XPath 2.0.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > 
  >     E. "A future version of XForms is expected to use XPath 2.0". We
  >     think it would be more appropriate to use XPath 2.0 in the current
  >     version.
  > 
  >     Even if you choose not to use XPath 2.0 now, we think you should
  >     consider laying the groundwork for a transition to XPath 2.0 in the
  >     current version. (: We noted that there are a few areas where transition
  >     to 2.0 will cause some compatibility problems - some of these are noted
  >     below. In these areas in particular we think it would be useful if
  >     XForms 1.1 provided alternatives to the current 1.0 syntax in a way
  >     that eases transition to XPath 2.0 later :)
  > 
  > 
  > 

15.11 Typo in 7.6 The XForms Function Library

PROBLEM ID: 40

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

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  The text "then an xforms-binding exception occurs." should read "then an
  xforms-binding-exception occurs." (missing "-").
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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 Michael,
  
  We will defer the adoption of XPath 2.0 until a later version (probably XForms
  2.0) 
  due to the huge ramifications on dependency calculations of things like XPath
  2.0's 'if'
  
  But we did deprecate "if" and we removed the return type rationalization for
  choose(), so we have taken steps to smooth the way for XPath 2.0.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > 
  >     E. "A future version of XForms is expected to use XPath 2.0". We
  >     think it would be more appropriate to use XPath 2.0 in the current
  >     version.
  > 
  >     Even if you choose not to use XPath 2.0 now, we think you should
  >     consider laying the groundwork for a transition to XPath 2.0 in the
  >     current version. (: We noted that there are a few areas where transition
  >     to 2.0 will cause some compatibility problems - some of these are noted
  >     below. In these areas in particular we think it would be useful if
  >     XForms 1.1 provided alternatives to the current 1.0 syntax in a way
  >     that eases transition to XPath 2.0 later :)
  > 
  > 
  > 
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  We will defer the adoption of XPath 2.0 until a later version (probably XForms
  2.0) 
  due to the huge ramifications on dependency calculations of things like XPath
  2.0's 'if'
  
  But we did deprecate "if" and we removed the return type rationalization for
  choose(), so we have taken steps to smooth the way for XPath 2.0.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > 
  >     E. "A future version of XForms is expected to use XPath 2.0". We
  >     think it would be more appropriate to use XPath 2.0 in the current
  >     version.
  > 
  >     Even if you choose not to use XPath 2.0 now, we think you should
  >     consider laying the groundwork for a transition to XPath 2.0 in the
  >     current version. (: We noted that there are a few areas where transition
  >     to 2.0 will cause some compatibility problems - some of these are noted
  >     below. In these areas in particular we think it would be useful if
  >     XForms 1.1 provided alternatives to the current 1.0 syntax in a way
  >     that eases transition to XPath 2.0 later :)
  > 
  > 
  > 

REPLY 2:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Erik,
  
  You are right. We will update the spec accordingly. 
  
  Many thanks.
  
  Nick Van den Bleeken
  For the Forms WG
  > 
  > The text "then an xforms-binding exception occurs." should read "then an
  > xforms-binding-exception occurs." (missing "-").
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

15.12 Section 7

PROBLEM ID: 139

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

NOTES:

  ACTION: Erik to address this with expanded wording about failure on undefined
  variable references and function calls.

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
  
      D. "XPath expressions that are not syntactically valid": should
      cover all static errors, not just syntax errors. (Other static
      errors include, for example, references to functions or variables
      not present in the context, and type errors detected statically).
  
  
  

FOLLOWUP 1:

  From: "Michael Kay" <mike@saxonica.com>
  
  That's fine.
  
  Undefined namespace prefixes are another possibility, in case you are
  enumerating them. 
  
  In fact XPath 1.0 doesn't distinguish very carefully between static and
  dynamic errors, so count("xyz") is an error that can be reported either
  statically or dynamically, similarly ($x|3).
  
  Michael Kay
  
  > -----Original Message-----
  > From: John Boyer [mailto:xforms-issues@mn.aptest.com] 
  > Sent: 24 October 2007 20:00
  > To: mike@saxonica.com
  > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
  > Subject: Re: Section 7 (PR#139)
  > 
  > Hi Michael,
  > 
  > The working group agrees that this is a problem and will fix 
  > it in the specification.  For XPath 1.0, the static errors 
  > appear to be limited to expression well-formedness, undefined 
  > variable references and undefined function references as 
  > issues with the [context node, position, size] are handled 
  > separately, i.e. their non-availability implies not executing 
  > the xpath and behaving as if empty nodeset were returned.
  > 
  > Please let us know if you have any further concerns about this issue.
  > 
  > Thank you,
  > John Boyer
  > 
  > > 
  > > 
  > > 
  > >     D. "XPath expressions that are not syntactically valid": should
  > >     cover all static errors, not just syntax errors. (Other static
  > >     errors include, for example, references to functions or 
  > variables
  > >     not present in the context, and type errors detected 
  > statically).
  > > 
  > > 
  > > 
  > > 
  

FOLLOWUP 2:

  From: w3c-xml-query-wg-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 Michael,
  
  The working group agrees that this is a problem and will fix it in the
  specification.  For XPath 1.0, the static errors appear to be limited to
  expression well-formedness, undefined variable references and undefined function
  references as issues with the [context node, position, size] are handled
  separately, i.e. their non-availability implies not executing the xpath and
  behaving as if empty nodeset were returned.
  
  Please let us know if you have any further concerns about this issue.
  
  Thank you,
  John Boyer
  
  > 
  > 
  > 
  >     D. "XPath expressions that are not syntactically valid": should
  >     cover all static errors, not just syntax errors. (Other static
  >     errors include, for example, references to functions or variables
  >     not present in the context, and type errors detected statically).
  > 
  > 
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Michael,
  
  The working group agrees that this is a problem and will fix it in the
  specification.  For XPath 1.0, the static errors appear to be limited to
  expression well-formedness, undefined variable references and undefined function
  references as issues with the [context node, position, size] are handled
  separately, i.e. their non-availability implies not executing the xpath and
  behaving as if empty nodeset were returned.
  
  Please let us know if you have any further concerns about this issue.
  
  Thank you,
  John Boyer
  
  > 
  > 
  > 
  >     D. "XPath expressions that are not syntactically valid": should
  >     cover all static errors, not just syntax errors. (Other static
  >     errors include, for example, references to functions or variables
  >     not present in the context, and type errors detected statically).
  > 
  > 
  > 
  > 

15.13 7.11.1

PROBLEM ID: 148

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

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
  
      M. Typo: "more that one instance"
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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 has been fixed.
  Thanks,
  John Boyer
  
  > 
  > 
  > 
  >     M. Typo: "more that one instance"
  > 
  > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  This has been fixed.
  Thanks,
  John Boyer
  
  > 
  > 
  > 
  >     M. Typo: "more that one instance"
  > 
  > 

15.14 Fw: Comment about location of choose() and event() functions in the spec

PROBLEM ID: 177

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

ORIGINAL MESSAGE:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 001CE33088257331_=
  Content-Type: text/plain; charset="US-ASCII"
  
  Erik Bruchez <ebruchez@orbeon.com> 
  Sent by: public-forms-request@w3.org
  08/01/2007 02:30 PM
  Please respond to
  ebruchez@orbeon.com
  
  
  To
  "Forms WG (new)" <public-forms@w3.org>
  cc
  www-forms-editor@w3.org
  Subject
  Comment about location of choose() and event() functions in the spec
  
  
  
  
  
  
  
  All,
  
  I notice that these two functions are under section "7.11 Node-set 
  Functions". This is not correct, as they can return types other than 
  node-set.
  
  The suggested fix is to create a section "7.12 Object Functions" and 
  move the current 7.12 to 7.13.
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  
  
  --=_alternative 001CE33088257331_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <table width=100%>
  <tr valign=top>
  <td width=40%><font size=1 face="sans-serif"><b>Erik Bruchez &lt;ebruchez@orbeon.com&gt;</b>
  </font>
  <br><font size=1 face="sans-serif">Sent by: public-forms-request@w3.org</font>
  <p><font size=1 face="sans-serif">08/01/2007 02:30 PM</font>
  <table border>
  <tr valign=top>
  <td bgcolor=white>
  <div align=center><font size=1 face="sans-serif">Please respond to<br>
  ebruchez@orbeon.com</font></div></table>
  <br>
  <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;Forms WG (new)&quot; &lt;public-forms@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">www-forms-editor@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">Comment about location of choose() and
  event() functions in the spec</font></table>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br>
  <br>
  <br><tt><font size=2><br>
  All,<br>
  <br>
  I notice that these two functions are under section &quot;7.11 Node-set
  <br>
  Functions&quot;. This is not correct, as they can return types other than
  <br>
  node-set.<br>
  <br>
  The suggested fix is to create a section &quot;7.12 Object Functions&quot;
  and <br>
  move the current 7.12 to 7.13.<br>
  <br>
  -Erik<br>
  <br>
  -- <br>
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way<br>
  </font></tt><a href=http://www.orbeon.com/><tt><font size=2>http://www.orbeon.com/</font></tt></a><tt><font size=2><br>
  <br>
  </font></tt>
  --=_alternative 001CE33088257331_=--
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Dear Erik,
  
  The working group accepts this proposal, and it has been implemented now.
  Please see section 7.10 of the editor's draft available from the working group
  home page.
  
  Thanks,
  John Boyer
  
  > This is a multipart message in MIME format.
  > --=_alternative 001CE33088257331_=
  > Content-Type: text/plain; charset="US-ASCII"
  > 
  > Erik Bruchez <ebruchez@orbeon.com> 
  > Sent by: public-forms-request@w3.org
  > 08/01/2007 02:30 PM
  > Please respond to
  > ebruchez@orbeon.com
  > 
  > 
  > To
  > "Forms WG (new)" <public-forms@w3.org>
  > cc
  > www-forms-editor@w3.org
  > Subject
  > Comment about location of choose() and event() functions in the spec
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > All,
  > 
  > I notice that these two functions are under section "7.11 Node-set 
  > Functions". This is not correct, as they can return types other than 
  > node-set.
  > 
  > The suggested fix is to create a section "7.12 Object Functions" and 
  > move the current 7.12 to 7.13.
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 
  > --=_alternative 001CE33088257331_=
  > Content-Type: text/html; charset="US-ASCII"
  > 
  > 
  > <table width=100%>
  > <tr valign=top>
  > <td width=40%><font size=1 face="sans-serif"><b>Erik Bruchez
  > <ebruchez@orbeon.com></b>
  > </font>
  > <br><font size=1 face="sans-serif">Sent by:
  public-forms-request@w3.org</font>
  > <p><font size=1 face="sans-serif">08/01/2007 02:30 PM</font>
  > <table border>
  > <tr valign=top>
  > <td bgcolor=white>
  > <div align=center><font size=1 face="sans-serif">Please respond to<br>
  > ebruchez@orbeon.com</font></div></table>
  > <br>
  > <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">"Forms WG (new)"
  > <public-forms@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-editor@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">Comment about location of choose() and
  > event() functions in the spec</font></table>
  > <br>
  > <table>
  > <tr valign=top>
  > <td>
  > <td></table>
  > <br></table>
  > <br>
  > <br>
  > <br><tt><font size=2><br>
  > All,<br>
  > <br>
  > I notice that these two functions are under section "7.11 Node-set
  > <br>
  > Functions". This is not correct, as they can return types other than
  > <br>
  > node-set.<br>
  > <br>
  > The suggested fix is to create a section "7.12 Object Functions"
  > and <br>
  > move the current 7.12 to 7.13.<br>
  > <br>
  > -Erik<br>
  > <br>
  > -- <br>
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way<br>
  > </font></tt><a href=http://www.orbeon.com/><tt><font
  > size=2>http://www.orbeon.com/</font></tt></a><tt><font size=2><br>
  > <br>
  > </font></tt>
  > --=_alternative 001CE33088257331_=--
  > 
  > 

15.15 [LC] 5.2.6 xforms:ID-card-number and 7.8.7 The luhn() Function

PROBLEM ID: 63

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

NOTES:

  The resolution was card-number for the type and is-card-number() for the
  function.
  
  This is only substantive in the sense that the names were changed, which does
  not invalidate prior implementation experiences with the features.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#id-card-type
  http://www.w3.org/TR/xforms11/#fn-luhn
  
  "The complementary XPath function luhn() should be used to validate
  that the ID number conforms to the specification."
  
  I imagine that almost exclusively these will be used like this:
  
         <bind nodeset="cc" type="ID-card-number" constraint="luhn()" />
  
  While I applaud the recognition of computer scientists who have
  contributed to society, I fear that this is too hard to remember for
  this single occurring case. May I propose as easier to cope with
  something along the lines of:
  
         <bind nodeset="cc" type="card-number" constraint="card-number()" />
  
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Steven,
  
  We will change the Change ID-card-number type to card-number and change name of
  the luhn() function to is-card-number().
  
  Regards,
  
  Nick Van den Bleeken
  
  
  > 
  > http://www.w3.org/TR/xforms11/#id-card-type
  > http://www.w3.org/TR/xforms11/#fn-luhn
  > 
  > "The complementary XPath function luhn() should be used to validate
  > that the ID number conforms to the specification."
  > 
  > I imagine that almost exclusively these will be used like this:
  > 
  >        <bind nodeset="cc" type="ID-card-number" constraint="luhn()" />
  > 
  > While I applaud the recognition of computer scientists who have
  > contributed to society, I fear that this is too hard to remember for
  > this single occurring case. May I propose as easier to cope with
  > something along the lines of:
  > 
  >        <bind nodeset="cc" type="card-number" constraint="card-number()" />
  > 
  > 
  > 

15.16 Last call comment: XForms 1.1 is missing a string compare capability

PROBLEM ID: 44

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

NOTES:

  This is substantive in that it adds a function, but we do not expect an
  objection since it adds a function commensurate with the two parameter version
  of the same function appearing in XPath 2.0, which is a recommendation.  This is
  part of our long term shift toward XPath 2.0.

ORIGINAL MESSAGE:

  From: "John Boyer" <boyerj@ca.ibm.com>
  
  1.1 has a requirement to allow search for data by a key value.  Although
  the detail text doesn't strictly mention it, I expected that our addition
  of the while attribute to XForms actions allowed us to do a search of
  where to put a new piece of data, and the required improvments to insert
  then allowed us to put it there.
  
  We can do this if the "key" is a number, but due to a limitation of XPath
  that I think we did not really note until recently, we cannot do the same
  if the key data is a string such as a name.  This means it is not possible
  for an XForm to maintain the ordered nature of a list of data under insert
  mutation.
  
  This is a trivially obvious use case that I *thought* we were accounting
  for, and it is easily solved by adding a string-compare() function to the
  XForms function library for XPath, and it should be easy to define it to
  be compatible with string comparison available in XPath 2.0.
  
  Some have complained that since XPath 2 has this, then the right answer is
  to adopt XPath 2.  In principle and in an ideal world, sure we'd get right
  on that, but we should not leave such a gaping hole in XForms 1.1, which
  is still based on XPath 1.0.  Since XPath 1.0 already contains the desired
  feature (the extensibility to allow us to define the function we need),
  there should be nothing wrong with using that feature, esp. if we define a
  compatible function for later upward mobility.  The argument that we
  shouldn't use the XPath 1.0 feature of extensibility because XPath 2 has
  this piece of overlapping functionality is problematic because the
  following conclusion is that we should not add anything since it might
  conflict with XPath 3.0.  If you think this can't happen, observe that it
  already has-- the if() function we desperately needed now conflicts with
  XPath 2.0.
  
  Conclusion: Please solve the problem that we can only maintain ordered
  numeric data and not ordered string data by adding a simple
  string-compare() function.
  
  Thanks,
  John M. Boyer, Ph.D.
  STSM: Workplace Forms Architect and Researcher
  Co-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
  

FOLLOWUP 1:

  From: "Hickey, Marianne" <marianne.hickey@hp.com>
  
  I am out of the office on extended leave and am not currently checking email.
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  John,
  
  we accepted your proposal and edited the spec accordingly.
  
  Regards,
  Ulrich Lissé
  For the Forms WG

REPLY 2:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  We have deprecated if().  It is still supported, but authors and design tool
  creators have been encouraged to change over to using choose().  We also removed
  return type rationalization from choose() to make it more compatible with the
  XPath 2.0 if construct.
  
  Adoption of XPath 2.0 is likely to correspond to XForms 2.0.  As a major version
  change to the language, it will be safe for us to drop support for if() in that
  version. We expect to also have an XForms 1.2, and we will likely have to leave
  if() as supported but deprecated in that language version too.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  >     I. The if() function poses particular problems because if() is not
  >     allowed as a function name in XPath 2.0 for syntactic reasons.
  > 
  >     If your functions were namespace qualified, this would be no
  >     problem. This is an example where thinking of your transition
  >     strategy to XPath 2.0 would be important.
  > 
  > 
  > 

15.17 Comments 7.7.2

PROBLEM ID: 144

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

NOTES:

  This is barely substantive in that we removed a subtle semantic on the choose()
  function to align it with the decision structure available in XPath 2.0.
  
  Detailed notes:
  We have deprecated if().  It is still supported, but authors and design tool
  creators have been encouraged to change over to using choose().  We also
  removed
  return type rationalization from choose() to make it more compatible with the
  XPath 2.0 if construct.
  
  Adoption of Xpath 2.0 is likely to correspond to XForms 2.0.  As a major
  version
  change to the language, it will be safe for us to drop support for if() in that
  version.  We expect to also have an XForms 1.2, and we will likely have to
  leave
  if() as supported but deprecated in that language version too.

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
      I. The if() function poses particular problems because if() is not
      allowed as a function name in XPath 2.0 for syntactic reasons.
  
      If your functions were namespace qualified, this would be no
      problem. This is an example where thinking of your transition
      strategy to XPath 2.0 would be important.
  
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  We have deprecated if().  It is still supported, but authors and design tool
  creators have been encouraged to change over to using choose().  We also removed
  return type rationalization from choose() to make it more compatible with the
  XPath 2.0 if construct.
  
  Adoption of XPath 2.0 is likely to correspond to XForms 2.0.  As a major version
  change to the language, it will be safe for us to drop support for if() in that
  version. We expect to also have an XForms 1.2, and we will likely have to leave
  if() as supported but deprecated in that language version too.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  >     I. The if() function poses particular problems because if() is not
  >     allowed as a function name in XPath 2.0 for syntactic reasons.
  > 
  >     If your functions were namespace qualified, this would be no
  >     problem. This is an example where thinking of your transition
  >     strategy to XPath 2.0 would be important.
  > 
  > 
  > 

15.18 [XForms 1.1] i18n comment: Require UTC as default for time zone information

PROBLEM ID: 11

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

NOTES:

  Process the following issues together : XPath/11, XPath/12, XPath/69, XPath/63

ORIGINAL MESSAGE:

  From: fsasaki@w3.org
  
  
  Comment from the i18n review of:
  http://www.w3.org/TR/2007/WD-xforms11-20070222/
  
  Comment 7
  At http://www.w3.org/International/reviews/0704-xforms11/
  Editorial/substantive: S
  Location in reviewed document:
  7.10.1
  Require UTC as default for time zone information
  
  Comment:
  
    The now function returns the current system date and time as a string  
  value in the canonical XML Schema xsd:dateTime format. If time zone  
  information is available, it is included (normalized to UTC). If no time  
  zone information is available, an implementation default is used.
  
  Please require that the default is UTC. Otherwise the results of applying  
  this function by different implementations might lead to dateTime values  
  which are not totally ordered. See the
  Working with Time Zones  
  [http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e448]
    for further guidance. Btw., in e.g. sec. 7.10.2 \"The days-from-date()  
  Function\" you already require usage of UTC.
  
  
  
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Felix,
  
  We accept your comments and will change the text so that it clearly states that
  if the timezone information is not available, the implementation should return
  the time with Z appended.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  > Comment from the i18n review of:
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > 
  > Comment 7
  > At http://www.w3.org/International/reviews/0704-xforms11/
  > Editorial/substantive: S
  > Location in reviewed document:
  > 7.10.1
  > Require UTC as default for time zone information
  > 
  > Comment:
  > 
  >   The now function returns the current system date and time as a string  
  > value in the canonical XML Schema xsd:dateTime format. If time zone  
  > information is available, it is included (normalized to UTC). If no time  
  > zone information is available, an implementation default is used.
  > 
  > Please require that the default is UTC. Otherwise the results of applying  
  > this function by different implementations might lead to dateTime values  
  > which are not totally ordered. See the
  > Working with Time Zones  
  > [http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e448]
  >   for further guidance. Btw., in e.g. sec. 7.10.2 \"The days-from-date()  
  > Function\" you already require usage of UTC.
  > 
  > 
  > 
  > 
  > 

15.19 7.5.1

PROBLEM ID: 142

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

NOTES:

  An expression is dependent upon a node or function return result if a change to
  the node or function return result causes a change to the expression result.
  
  The set of dependents for an expression is called its dependency list.
  
  An expression is dynamically dependent on a node or function return result if a
  change to the node or function return result causes a change to the dependency
  list of the expression.
  
  The master dependency graph of the model is not automatically rebuilt in all
  cases in which a model binding expression's dependency list changes.  The
  insert
  and delete actions set the rebuild flag, so data mutations such as inserting or
  deleting element and attribute nodes do correspond to a rebuild.  However, if a
  model expression's dependency list is changed based on a change to a text value
  is changed by a form control or setvalue action, a rebuild is not automatically
  performed.  Similarly, changes that affect the return results of functions like
  id(), index() and now() do not automatically result in a rebuild.  An
  implementation does not forbid the use of dynamic dependencies in model binding
  expressions, however, form authors are encouraged to use them only when the
  rebuild action can be manually triggered to correspond account for the change
  of
  dependency list.
  
  Perhaps "restriction" is not the right word.  I think "limitation" is the right
  word.

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
  
      G. The concept of "dynamic dependencies" needs further
      explanation. It's very hard to understand what this section is
      saying. We believe you need a precise definition that states when
      there is a dynamic dependency.
  
      "there are restrictions on model binding expressions that create
      dynamic dependencies" -> you should tell us precisely what these
      restrictions are, and what an implementation should do if these
      restrictions are violated.
  

FOLLOWUP 1:

  From: w3c-xml-query-wg-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:
  ----------------------------------------------------------------------------
  
  
  Michael,
  
  we accept that a better definition for what happens when you use a dynamic
  dependency in the model is needed. We created an action item to produce new spec
  text.
  
  Regards,
  Ulrich Nicolas Lissé
  
  For the Forms WG
  
  >     G. The concept of "dynamic dependencies" needs further
  >     explanation. It's very hard to understand what this section is
  >     saying. We believe you need a precise definition that states when
  >     there is a dynamic dependency.
  > 
  >     "there are restrictions on model binding expressions that create
  >     dynamic dependencies" -> you should tell us precisely what these
  >     restrictions are, and what an implementation should do if these
  >     restrictions are violated.
  > 
  > 
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Michael,
  
  we accept that a better definition for what happens when you use a dynamic
  dependency in the model is needed. We created an action item to produce new spec
  text.
  
  Regards,
  Ulrich Nicolas Lissé
  
  For the Forms WG
  
  >     G. The concept of "dynamic dependencies" needs further
  >     explanation. It's very hard to understand what this section is
  >     saying. We believe you need a precise definition that states when
  >     there is a dynamic dependency.
  > 
  >     "there are restrictions on model binding expressions that create
  >     dynamic dependencies" -> you should tell us precisely what these
  >     restrictions are, and what an implementation should do if these
  >     restrictions are violated.
  > 
  > 

15.20 LC: Sections 7.2 and 7.3 should be in their own section

PROBLEM ID: 33

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

NOTES:

  These have been moved to the end of section 4 in the editor's draft.

ORIGINAL MESSAGE:

  From: "Mark Birbeck" <mark.birbeck@x-port.net>
  
  
  Section 7 is devoted to all things XPath, which doesn't really seem
  appropriate for sections 7.2 and 7.3.
  
  -- 
     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: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Mark,
  
  The working group accepts this last call comment and has decided to move the two
  sections to the end of Chapter 4, which contains all material related to
  accessing and updating the model.
  
  Thank you,
  John Boyer
  
  > 
  > Section 7 is devoted to all things XPath, which doesn't really seem
  > appropriate for sections 7.2 and 7.3.
  > 
  > -- 
  >    Mark Birbeck, formsPlayer
  > 
  >    mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  >    http://www.formsPlayer.com | http://internet-apps.blogspot.com
  > 
  >    standards. innovation.
  > 
  > 

15.21 [LC] 7.10.8 The seconds() Function

PROBLEM ID: 70

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

NOTES:

  Reply:
  seconds("P1Y2M") returns 0 and not NaN because the input is a valid duration
  but
  the seconds function doesn't takes months and years into account. However we
  will switch the first and second example so that the first example returns a
  not
  zero value.

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#fn-get-seconds-from-duration
  
  Please don't start examples off with an error case like this. First
  give some valid examples, and then some error examples (in the case of
  this first one because the parameter only contains years and months).
  
  Is there a rationale for why such examples return 0 instead of NaN?
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  These examples were from XForms 1.0.
  
  The order has been changed to start with a non-error case, and the updated
  example style for XForms 1.1 has been applied, which necessitated adding an
  explanation for the return values.
  
  Thanks,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#fn-get-seconds-from-duration
  > 
  > Please don't start examples off with an error case like this. First
  > give some valid examples, and then some error examples (in the case of
  > this first one because the parameter only contains years and months).
  > 
  > Is there a rationale for why such examples return 0 instead of NaN?
  > 
  > 

15.22 [XForms 1.1] i18n comment: Availability of time zone information unclear

PROBLEM ID: 12

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

NOTES:

  Process the following issues together : XPath/11, XPath/12, XPath/69, XPath/63

ORIGINAL MESSAGE:

  From: fsasaki@w3.org
  
  
  Comment from the i18n review of:
  http://www.w3.org/TR/2007/WD-xforms11-20070222/
  
  Comment 8.
  At http://www.w3.org/International/reviews/0704-xforms11/
  Editorial/substantive: S
  Location in reviewed document:
  7.10.6 and 7.10.7
  Availability of time zone information unclear
  
  Comment:
  
  Sec. 7.10.6 contains the statement:
  
  
    This function returns a lexical xsd:date obtained as if by the following  
  rules: the result of now() is converted to a local date based on the user  
  agent time zone information.
  
  > From this statement it is unclear what kind of indicator the user agent  
  > should use to provide time zone information. The same unclearness is in  
  > sec.7.10.7.
  
  
  
  

REPLY 1:

  From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com>
  
  Hello,
  
  the method by which the XForms processor gets the timezone info from the user
  agent is not specified because it is implementation-defined.
  
  Regards,
  Ulrich Nicolas Lissé.
  For the Forms WG
  
  > Comment from the i18n review of:
  > http://www.w3.org/TR/2007/WD-xforms11-20070222/
  > 
  > Comment 8.
  > At http://www.w3.org/International/reviews/0704-xforms11/
  > Editorial/substantive: S
  > Location in reviewed document:
  > 7.10.6 and 7.10.7
  > Availability of time zone information unclear
  > 
  > Comment:
  > 
  > Sec. 7.10.6 contains the statement:
  > 
  > 
  >   This function returns a lexical xsd:date obtained as if by the following  
  > rules: the result of now() is converted to a local date based on the user  
  > agent time zone information.
  > 
  >> From this statement it is unclear what kind of indicator the user agent  
  >> should use to provide time zone information. The same unclearness is in  
  >> sec.7.10.7.
  > 
  > 
  > 
  > 
  > 

15.23 Typo in 7.5.3 UI Binding Expressions

PROBLEM ID: 39

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

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  The text "Dynamic dependences" should read "Dynamic dependencies".
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

FOLLOWUP 1:

  From: "Michael Kay" <mike@saxonica.com>
  
  That's fine.
  
  Undefined namespace prefixes are another possibility, in case you are
  enumerating them. 
  
  In fact XPath 1.0 doesn't distinguish very carefully between static and
  dynamic errors, so count("xyz") is an error that can be reported either
  statically or dynamically, similarly ($x|3).
  
  Michael Kay
  
  > -----Original Message-----
  > From: John Boyer [mailto:xforms-issues@mn.aptest.com] 
  > Sent: 24 October 2007 20:00
  > To: mike@saxonica.com
  > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
  > Subject: Re: Section 7 (PR#139)
  > 
  > Hi Michael,
  > 
  > The working group agrees that this is a problem and will fix 
  > it in the specification.  For XPath 1.0, the static errors 
  > appear to be limited to expression well-formedness, undefined 
  > variable references and undefined function references as 
  > issues with the [context node, position, size] are handled 
  > separately, i.e. their non-availability implies not executing 
  > the xpath and behaving as if empty nodeset were returned.
  > 
  > Please let us know if you have any further concerns about this issue.
  > 
  > Thank you,
  > John Boyer
  > 
  > > 
  > > 
  > > 
  > >     D. "XPath expressions that are not syntactically valid": should
  > >     cover all static errors, not just syntax errors. (Other static
  > >     errors include, for example, references to functions or 
  > variables
  > >     not present in the context, and type errors detected 
  > statically).
  > > 
  > > 
  > > 
  > > 
  

FOLLOWUP 2:

  From: w3c-xml-query-wg-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 Michael,
  
  The working group agrees that this is a problem and will fix it in the
  specification.  For XPath 1.0, the static errors appear to be limited to
  expression well-formedness, undefined variable references and undefined function
  references as issues with the [context node, position, size] are handled
  separately, i.e. their non-availability implies not executing the xpath and
  behaving as if empty nodeset were returned.
  
  Please let us know if you have any further concerns about this issue.
  
  Thank you,
  John Boyer
  
  > 
  > 
  > 
  >     D. "XPath expressions that are not syntactically valid": should
  >     cover all static errors, not just syntax errors. (Other static
  >     errors include, for example, references to functions or variables
  >     not present in the context, and type errors detected statically).
  > 
  > 
  > 
  > 
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Erik,
  
  You are right. We will update the spec accordingly. 
  
  Many thanks.
  
  Nick Van den Bleeken
  For the Forms WG
  > 
  > The text "Dynamic dependences" should read "Dynamic dependencies".
  > 
  > -Erik
  > 
  > -- 
  > 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 Michael,
  
  The working group agrees that this is a problem and will fix it in the
  specification.  For XPath 1.0, the static errors appear to be limited to
  expression well-formedness, undefined variable references and undefined function
  references as issues with the [context node, position, size] are handled
  separately, i.e. their non-availability implies not executing the xpath and
  behaving as if empty nodeset were returned.
  
  Please let us know if you have any further concerns about this issue.
  
  Thank you,
  John Boyer
  
  > 
  > 
  > 
  >     D. "XPath expressions that are not syntactically valid": should
  >     cover all static errors, not just syntax errors. (Other static
  >     errors include, for example, references to functions or variables
  >     not present in the context, and type errors detected statically).
  > 
  > 
  > 
  > 

15.24 Re: id function and xsi:type

PROBLEM ID: 152

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

ORIGINAL MESSAGE:

  From: Leigh.klotz@Xerox.com
  
  Full_Name: Leigh L. Klotz, Jr.
  Submission from: (NULL) (13.1.101.37)
  
  
  
  --------------------------------------------------------------------------------
  From: John Boyer [mailto:boyerj@ca.ibm.com] 
  Sent: Tuesday, June 19, 2007 12:07 PM
  To: Klotz, Leigh
  Cc: public-forms@w3.org
  Subject: Re: id function and xsi:type
  
  
  
  Hi Leigh, 
  
  Can you please make sure this issue is entered into the issue system. 
  
  Thanks, 
  
  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
  
  
  
  
  "Leigh L Klotz, Jr." <Leigh.Klotz@xerox.com> 
  Sent by: www-forms-editor-request@w3.org 
  06/14/2007 06:31 AM 
   To www-forms-editor@w3.org  
  cc  
  Subject id function and xsi:type 
  
    
  
   
  
  
  
  
  In http://www.w3.org/TR/xforms11/#fn-id it says
  
  An element node can be assigned an ID by means of an xml:id attribute or an
  attribute that is assigned the type ID by a DTD or xsd:ID or any type
  derived
  from xsd:ID by an XML schema, an xsi:type attribute, or the type model item
  property.
  
  I do not see how xsi:type can be used to assign type xsd:ID to an
  attribute, since it appears that xsi:type can assign types only to
  elements.
  
  Leigh.
  
  
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Leigh,
  
  You are correct, of course.  Please see the diff-marked version now available
  from the editor's draft section of the Forms WG website, and let us know if you
  have any further concerns about this issue.
  
  Thanks,
  John Boyer
  
  > Full_Name: Leigh L. Klotz, Jr.
  > Submission from: (NULL) (13.1.101.37)
  > 
  > 
  > 
  > --------------------------------------------------------------------------------
  > From: John Boyer [mailto:boyerj@ca.ibm.com] 
  > Sent: Tuesday, June 19, 2007 12:07 PM
  > To: Klotz, Leigh
  > Cc: public-forms@w3.org
  > Subject: Re: id function and xsi:type
  > 
  > 
  > 
  > Hi Leigh, 
  > 
  > Can you please make sure this issue is entered into the issue system. 
  > 
  > Thanks, 
  > 
  > 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
  > 
  > 
  > 
  > 
  > "Leigh L Klotz, Jr." <Leigh.Klotz@xerox.com> 
  > Sent by: www-forms-editor-request@w3.org 
  > 06/14/2007 06:31 AM 
  >  To www-forms-editor@w3.org  
  > cc  
  > Subject id function and xsi:type 
  > 
  >   
  > 
  >  
  > 
  > 
  > 
  > 
  > In http://www.w3.org/TR/xforms11/#fn-id it says
  > 
  > An element node can be assigned an ID by means of an xml:id attribute or an
  > attribute that is assigned the type ID by a DTD or xsd:ID or any type
  > derived
  > from xsd:ID by an XML schema, an xsi:type attribute, or the type model item
  > property.
  > 
  > I do not see how xsi:type can be used to assign type xsd:ID to an
  > attribute, since it appears that xsi:type can assign types only to
  > elements.
  > 
  > Leigh.
  > 
  > 
  > 
  > 
  > 

15.25 7.4

PROBLEM ID: 141

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

NOTES:

  Evaluation context section (now 7.2) is very precisely tailored to our needs
  based on XPath 1.0, which we
  must use for XForms 1.1.  It also accounts for content repetition that XForms
  performs, which is why the section contains more information than what might be
  described for the evaluation context of a single XPath expression.
  There is nothing specific to accept or reject here, but we have not made any
  changes to section 7.4 based on this comment.
  

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
      F. The XPath 2.0 specification provides a much more formal and
      comprehensive description of the evaluation context, which would
      provide a more solid basis for this part of the specification.
      (: You could use this as a guide even for XPath 1.0 :)
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  We will defer the adoption of XPath 2.0 until a later version (probably XForms
  2.0) due to reasons we mentioned in an earlier reply. Therefore we can't use the
  XPath 2.0 description of evaluation context.
  
  Moreover the evaluation context section (now 7.2) is also very precisely
  tailored to our needs based on XPath 1.0, which we must use for XForms 1.1.  It
  also accounts for content repetition that XForms performs, which is why the
  section contains more information than what might be described for the
  evaluation context of a single XPath expression.
  
  Regards,
  
  Nick Van den Bleeken
  
  > 
  >     F. The XPath 2.0 specification provides a much more formal and
  >     comprehensive description of the evaluation context, which would
  >     provide a more solid basis for this part of the specification.
  >     (: You could use this as a guide even for XPath 1.0 :)
  > 
  > 

15.26 7.10.4

PROBLEM ID: 147

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

NOTES:

  This is a several-years-old XForms 1.0 function defined for use with XPath 1.0.
  The semantic differences should probably be addressed in XForms 2.0 when we
  actually move to XPath 2.0.
  
  Regarding leap seconds, I would guess the answer is no, and such should be said
  both in this function and in seconds-to-dateTime().

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
      L. The seconds-from-dateTime() function poses a particular problem
      because XPath 2.0 offers a function with the same name and
      different semantics.
  
      You should define whether leap second are taken into account, and
      if so, specify how.
  

FOLLOWUP 1:

  From: "Michael Kay" <mike@saxonica.com>
  
   
  Well, I'm clearly not going to persuade you, but it seems a very
  short-sighted attitude to me.
  
  If the XForms specification doesn't support XPath 2.0 until 2010, then an
  increasing number of vendors will support it unilaterally (some already do),
  which means the coexistence and transition issues will be even worse.
  
  In any, case, the argument seems a bit like the millenium bug: we won't
  worry about this problem because it will be three years before users notice
  it.
  
  Michael Kay
  
  
  > -----Original Message-----
  > From: John Boyer [mailto:xforms-issues@mn.aptest.com] 
  > Sent: 18 October 2007 09:27
  > To: mike@saxonica.com
  > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
  > Subject: Re: 7.10.4 (PR#147)
  > 
  > Hi Michael,
  > 
  > I received your follow-up recommending that we add 
  > seconds-from-1970() and deprecate seconds-from-dataTime() to 
  > make future updating to XForms 2.0/XPath 2.0 easier.
  > 
  > This only seems to add confusing complexities to XForms 1.1 
  > in order to make at best a minor improvement to the future 
  > update capabilities.  The update of 1.x content to XForms 2.0 
  > should have much bigger issues than this.
  > It is also by no means clear that a form author undergoing 
  > such a large update of content would even want to retain the 
  > 1970 semantic anyway because the typical call of these 
  > functions is to do date math and comparisons.
  > 
  > Finally, it should be noted that the current estimated 
  > (optimistic) timeframe for an XForms 2.0 recommendation is 
  > the end of 2010.
  > 
  > Best regards,
  > John Boyer
  > 
  > > 
  > > 
  > >     L. The seconds-from-dateTime() function poses a 
  > particular problem
  > >     because XPath 2.0 offers a function with the same name and
  > >     different semantics.
  > > 
  > >     You should define whether leap second are taken into 
  > account, and
  > >     if so, specify how.
  > > 
  > > 
  

FOLLOWUP 2:

  From: w3c-xml-query-wg-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 Michael,
  
  I received your follow-up recommending that we add seconds-from-1970() and
  deprecate seconds-from-dataTime() to make future updating to XForms 2.0/XPath
  2.0 easier.
  
  This only seems to add confusing complexities to XForms 1.1 in order to make at
  best a minor improvement to the future update capabilities.  The update of 1.x
  content to XForms 2.0 should have much bigger issues than this.
  It is also by no means clear that a form author undergoing such a large update
  of content would even want to retain the 1970 semantic anyway because the
  typical call of these functions is to do date math and comparisons.
  
  Finally, it should be noted that the current estimated (optimistic) timeframe
  for an XForms 2.0 recommendation is the end of 2010.
  
  Best regards,
  John Boyer
  
  > 
  > 
  >     L. The seconds-from-dateTime() function poses a particular problem
  >     because XPath 2.0 offers a function with the same name and
  >     different semantics.
  > 
  >     You should define whether leap second are taken into account, and
  >     if so, specify how.
  > 
  > 
  

FOLLOWUP 3:

  From: w3c-xml-query-wg-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 Michael,
  
  The seconds-from-dateTime() function is a several-years-old XForms 1.0 function
  defined for use with XPath 1.0.
  The semantic differences should probably be addressed in XForms 2.0 when we
  actually move to XPath 2.0.
  
  Regarding leap seconds, we will add text that states that leap seconds are not
  supported.
  
  Regards,
  
  Nick Van den Bleeken
  > 
  > 
  >     L. The seconds-from-dateTime() function poses a particular problem
  >     because XPath 2.0 offers a function with the same name and
  >     different semantics.
  > 
  >     You should define whether leap second are taken into account, and
  >     if so, specify how.
  > 
  > 
  

FOLLOWUP 4:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 0036970F88257378_=
  Content-Type: text/plain; charset="US-ASCII"
  
  Hi Michael,
  
  I agree that in the general case, without looking at the specific 
  functions at hand, it might seem very short-sighted.
  
  The real question that needs an answer is whether the difference of 
  semantic breaks the real uses cases we have for this function, which are
  
  1) Compare two dates 
  seconds-from-dateTime(D1) &lt; seconds-from-dateTime(D2)
  
  2) Difference, which can be string manipulated into a duration if needed
  seconds-from-dateTime(D1) - seconds-from-dateTime(D2)
  
  3) Compute 2 hours from now
  adjust-dateTime-to-timezone(seconds-to-dateTime(seconds-from-dateTime(now()) 
  + 7200))
  
  Can you let us know please if you think the difference of semantic will 
  break one of these three expressions?
  
  Thank you,
  John M. Boyer, Ph.D.
  STSM: Lotus Forms Architect and Researcher
  Chair, W3C Forms Working Group
  Workplace, Portal and Collaboration Software
  IBM Victoria Software Lab
  E-Mail: boyerj@ca.ibm.com 
  
  Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
  
  
  
  
  
  "Michael Kay" <mike@saxonica.com> 
  Sent by: www-forms-editor-request@w3.org
  10/18/2007 01:53 AM
  
  To
  "'John Boyer'" <xforms-issues@mn.aptest.com>
  cc
  <w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org>
  Subject
  RE: 7.10.4 (PR#147)
  
  
  
  
  
  
  
   
  Well, I'm clearly not going to persuade you, but it seems a very
  short-sighted attitude to me.
  
  If the XForms specification doesn't support XPath 2.0 until 2010, then an
  increasing number of vendors will support it unilaterally (some already 
  do),
  which means the coexistence and transition issues will be even worse.
  
  In any, case, the argument seems a bit like the millenium bug: we won't
  worry about this problem because it will be three years before users 
  notice
  it.
  
  Michael Kay
  
  
  > -----Original Message-----
  > From: John Boyer [mailto:xforms-issues@mn.aptest.com] 
  > Sent: 18 October 2007 09:27
  > To: mike@saxonica.com
  > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
  > Subject: Re: 7.10.4 (PR#147)
  > 
  > Hi Michael,
  > 
  > I received your follow-up recommending that we add 
  > seconds-from-1970() and deprecate seconds-from-dataTime() to 
  > make future updating to XForms 2.0/XPath 2.0 easier.
  > 
  > This only seems to add confusing complexities to XForms 1.1 
  > in order to make at best a minor improvement to the future 
  > update capabilities.  The update of 1.x content to XForms 2.0 
  > should have much bigger issues than this.
  > It is also by no means clear that a form author undergoing 
  > such a large update of content would even want to retain the 
  > 1970 semantic anyway because the typical call of these 
  > functions is to do date math and comparisons.
  > 
  > Finally, it should be noted that the current estimated 
  > (optimistic) timeframe for an XForms 2.0 recommendation is 
  > the end of 2010.
  > 
  > Best regards,
  > John Boyer
  > 
  > > 
  > > 
  > >     L. The seconds-from-dateTime() function poses a 
  > particular problem
  > >     because XPath 2.0 offers a function with the same name and
  > >     different semantics.
  > > 
  > >     You should define whether leap second are taken into 
  > account, and
  > >     if so, specify how.
  > > 
  > > 
  
  
  
  
  --=_alternative 0036970F88257378_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <br><font size=2 face="sans-serif">Hi Michael,</font>
  <br>
  <br><font size=2 face="sans-serif">I agree that in the general case, without
  looking at the specific functions at hand, it might seem very short-sighted.</font>
  <br>
  <br><font size=2 face="sans-serif">The real question that needs an answer
  is whether the difference of semantic breaks the real uses cases we have
  for this function, which are</font>
  <br>
  <br><font size=2 face="sans-serif">1) Compare two dates </font>
  <br><font size=2 face="sans-serif">seconds-from-dateTime(D1) &amp;lt; seconds-from-dateTime(D2)</font>
  <br>
  <br><font size=2 face="sans-serif">2) Difference, which can be string manipulated
  into a duration if needed</font>
  <br><font size=2 face="sans-serif">seconds-from-dateTime(D1) - seconds-from-dateTime(D2)</font>
  <br>
  <br><font size=2 face="sans-serif">3) Compute 2 hours from now</font>
  <br><font size=2 face="sans-serif">adjust-dateTime-to-timezone(seconds-to-dateTime(seconds-from-dateTime(now())
  + 7200))</font>
  <br>
  <br><font size=2 face="sans-serif">Can you let us know please if you think
  the difference of semantic will break one of these three expressions?</font>
  <br>
  <br><font size=2 face="sans-serif">Thank you,</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;Michael Kay&quot;
  &lt;mike@saxonica.com&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">10/18/2007 01:53 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;</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;w3c-xml-query-wg@w3.org&gt;, &lt;www-forms-editor@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: 7.10.4 (PR#147)</font></table>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br>
  <br>
  <br><tt><font size=2><br>
   <br>
  Well, I'm clearly not going to persuade you, but it seems a very<br>
  short-sighted attitude to me.<br>
  <br>
  If the XForms specification doesn't support XPath 2.0 until 2010, then
  an<br>
  increasing number of vendors will support it unilaterally (some already
  do),<br>
  which means the coexistence and transition issues will be even worse.<br>
  <br>
  In any, case, the argument seems a bit like the millenium bug: we won't<br>
  worry about this problem because it will be three years before users notice<br>
  it.<br>
  <br>
  Michael Kay<br>
  <br>
  <br>
  &gt; -----Original Message-----<br>
  &gt; From: John Boyer [</font></tt><a href="mailto:xforms-issues@mn.aptest.com"><tt><font size=2>mailto:xforms-issues@mn.aptest.com</font></tt></a><tt><font size=2>]
  <br>
  &gt; Sent: 18 October 2007 09:27<br>
  &gt; To: mike@saxonica.com<br>
  &gt; Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org<br>
  &gt; Subject: Re: 7.10.4 (PR#147)<br>
  &gt; <br>
  &gt; Hi Michael,<br>
  &gt; <br>
  &gt; I received your follow-up recommending that we add <br>
  &gt; seconds-from-1970() and deprecate seconds-from-dataTime() to <br>
  &gt; make future updating to XForms 2.0/XPath 2.0 easier.<br>
  &gt; <br>
  &gt; This only seems to add confusing complexities to XForms 1.1 <br>
  &gt; in order to make at best a minor improvement to the future <br>
  &gt; update capabilities. &nbsp;The update of 1.x content to XForms 2.0
  <br>
  &gt; should have much bigger issues than this.<br>
  &gt; It is also by no means clear that a form author undergoing <br>
  &gt; such a large update of content would even want to retain the <br>
  &gt; 1970 semantic anyway because the typical call of these <br>
  &gt; functions is to do date math and comparisons.<br>
  &gt; <br>
  &gt; Finally, it should be noted that the current estimated <br>
  &gt; (optimistic) timeframe for an XForms 2.0 recommendation is <br>
  &gt; the end of 2010.<br>
  &gt; <br>
  &gt; Best regards,<br>
  &gt; John Boyer<br>
  &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; &nbsp; &nbsp; L. The seconds-from-dateTime() function poses a
  <br>
  &gt; particular problem<br>
  &gt; &gt; &nbsp; &nbsp; because XPath 2.0 offers a function with the same
  name and<br>
  &gt; &gt; &nbsp; &nbsp; different semantics.<br>
  &gt; &gt; <br>
  &gt; &gt; &nbsp; &nbsp; You should define whether leap second are taken
  into <br>
  &gt; account, and<br>
  &gt; &gt; &nbsp; &nbsp; if so, specify how.<br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  <br>
  <br>
  </font></tt>
  <br>
  --=_alternative 0036970F88257378_=--
  

FOLLOWUP 5:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 006DA7FF8825738E_=
  Content-Type: text/plain; charset="US-ASCII"
  
  Hi Michael, 
  
  Could you please let us know what should be put on the final disposition 
  of this comment?
  We did indicate that our function does not recognize leap seconds (in 
  accord with XPath 2.0).
  Based on the use cases elaborated at the end of the discussion thread 
  (topmost below), would you be willing to agree (however reluctantly) with 
  the group's desire to proceed with this longstanding XForms 1.0 function 
  for now and deal with any semantic differences with the XPath 2.0 when we 
  transition to XPath 2.0 in XForms 2.0?
  
  Or do you want us to record a disagree result, or do you want us to record 
  a formal objection? 
  
  Thank you for your consideration.  If you could please let us know by 
  Monday, this would help as we are coming up to the transition meeting with 
  the director and the current setting is 'No response' to the end of the 
  thread.
  
  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
  
  
  
  
  
  John Boyer/CanWest/IBM@IBMCA 
  Sent by: www-forms-editor-request@w3.org
  10/18/2007 02:56 AM
  
  To
  "Michael Kay" <mike@saxonica.com>
  cc
  w3c-xml-query-wg@w3.org, www-forms-editor@w3.org, 
  www-forms-editor-request@w3.org, "'John Boyer'" 
  <xforms-issues@mn.aptest.com>
  Subject
  RE: 7.10.4 (PR#147)
  
  
  
  
  
  
  
  Hi Michael, 
  
  I agree that in the general case, without looking at the specific 
  functions at hand, it might seem very short-sighted. 
  
  The real question that needs an answer is whether the difference of 
  semantic breaks the real uses cases we have for this function, which are 
  
  1) Compare two dates 
  seconds-from-dateTime(D1) &lt; seconds-from-dateTime(D2) 
  
  2) Difference, which can be string manipulated into a duration if needed 
  seconds-from-dateTime(D1) - seconds-from-dateTime(D2) 
  
  3) Compute 2 hours from now 
  adjust-dateTime-to-timezone(seconds-to-dateTime(seconds-from-dateTime(now()) 
  + 7200)) 
  
  Can you let us know please if you think the difference of semantic will 
  break one of these three expressions? 
  
  Thank you, 
  John M. Boyer, Ph.D.
  STSM: Lotus Forms Architect and Researcher
  Chair, W3C Forms Working Group
  Workplace, Portal and Collaboration Software
  IBM Victoria Software Lab
  E-Mail: boyerj@ca.ibm.com 
  
  Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
  
  
  
  
  "Michael Kay" <mike@saxonica.com> 
  Sent by: www-forms-editor-request@w3.org 
  10/18/2007 01:53 AM 
  
  
  To
  "'John Boyer'" <xforms-issues@mn.aptest.com> 
  cc
  <w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org> 
  Subject
  RE: 7.10.4 (PR#147)
  
  
  
  
  
  
  
  
  
  
  Well, I'm clearly not going to persuade you, but it seems a very
  short-sighted attitude to me.
  
  If the XForms specification doesn't support XPath 2.0 until 2010, then an
  increasing number of vendors will support it unilaterally (some already 
  do),
  which means the coexistence and transition issues will be even worse.
  
  In any, case, the argument seems a bit like the millenium bug: we won't
  worry about this problem because it will be three years before users 
  notice
  it.
  
  Michael Kay
  
  
  > -----Original Message-----
  > From: John Boyer [mailto:xforms-issues@mn.aptest.com] 
  > Sent: 18 October 2007 09:27
  > To: mike@saxonica.com
  > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
  > Subject: Re: 7.10.4 (PR#147)
  > 
  > Hi Michael,
  > 
  > I received your follow-up recommending that we add 
  > seconds-from-1970() and deprecate seconds-from-dataTime() to 
  > make future updating to XForms 2.0/XPath 2.0 easier.
  > 
  > This only seems to add confusing complexities to XForms 1.1 
  > in order to make at best a minor improvement to the future 
  > update capabilities.  The update of 1.x content to XForms 2.0 
  > should have much bigger issues than this.
  > It is also by no means clear that a form author undergoing 
  > such a large update of content would even want to retain the 
  > 1970 semantic anyway because the typical call of these 
  > functions is to do date math and comparisons.
  > 
  > Finally, it should be noted that the current estimated 
  > (optimistic) timeframe for an XForms 2.0 recommendation is 
  > the end of 2010.
  > 
  > Best regards,
  > John Boyer
  > 
  > > 
  > > 
  > >     L. The seconds-from-dateTime() function poses a 
  > particular problem
  > >     because XPath 2.0 offers a function with the same name and
  > >     different semantics.
  > > 
  > >     You should define whether leap second are taken into 
  > account, and
  > >     if so, specify how.
  > > 
  > > 
  
  
  
  
  --=_alternative 006DA7FF8825738E_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <br><font size=2 face="sans-serif">Hi Michael, </font>
  <br>
  <br><font size=2 face="sans-serif">Could you please let us know what should
  be put on the final disposition of this comment?</font>
  <br><font size=2 face="sans-serif">We did indicate that our function does
  not recognize leap seconds (in accord with XPath 2.0).</font>
  <br><font size=2 face="sans-serif">Based on the use cases elaborated at
  the end of the discussion thread (topmost below), would you be willing
  to agree (however reluctantly) with the group's desire to proceed with
  this longstanding XForms 1.0 function for now and deal with any semantic
  differences with the XPath 2.0 when we transition to XPath 2.0 in XForms
  2.0?</font>
  <br>
  <br><font size=2 face="sans-serif">Or do you want us to record a disagree
  result, or do you want us to record a formal objection? </font>
  <br>
  <br><font size=2 face="sans-serif">Thank you for your consideration. &nbsp;If
  you could please let us know by Monday, this would help as we are coming
  up to the transition meeting with the director and the current setting
  is 'No response' to the end of the thread.</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>
  <br>
  <br>
  <br>
  <table width=100%>
  <tr valign=top>
  <td width=40%><font size=1 face="sans-serif"><b>John Boyer/CanWest/IBM@IBMCA</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">10/18/2007 02:56 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;Michael Kay&quot; &lt;mike@saxonica.com&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">w3c-xml-query-wg@w3.org, www-forms-editor@w3.org,
  www-forms-editor-request@w3.org, &quot;'John Boyer'&quot; &lt;xforms-issues@mn.aptest.com&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: 7.10.4 (PR#147)</font></table>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br>
  <br>
  <br><font size=2 face="sans-serif"><br>
  Hi Michael,</font><font size=3> <br>
  </font><font size=2 face="sans-serif"><br>
  I agree that in the general case, without looking at the specific functions
  at hand, it might seem very short-sighted.</font><font size=3> <br>
  </font><font size=2 face="sans-serif"><br>
  The real question that needs an answer is whether the difference of semantic
  breaks the real uses cases we have for this function, which are</font><font size=3>
  <br>
  </font><font size=2 face="sans-serif"><br>
  1) Compare two dates <br>
  seconds-from-dateTime(D1) &amp;lt; seconds-from-dateTime(D2)</font><font size=3>
  <br>
  </font><font size=2 face="sans-serif"><br>
  2) Difference, which can be string manipulated into a duration if needed</font><font size=3>
  </font><font size=2 face="sans-serif"><br>
  seconds-from-dateTime(D1) - seconds-from-dateTime(D2)</font><font size=3>
  <br>
  </font><font size=2 face="sans-serif"><br>
  3) Compute 2 hours from now</font><font size=3> </font><font size=2 face="sans-serif"><br>
  adjust-dateTime-to-timezone(seconds-to-dateTime(seconds-from-dateTime(now())
  + 7200))</font><font size=3> <br>
  </font><font size=2 face="sans-serif"><br>
  Can you let us know please if you think the difference of semantic will
  break one of these three expressions?</font><font size=3> <br>
  </font><font size=2 face="sans-serif"><br>
  Thank you,</font><font size=3> </font><font size=2 face="sans-serif"><br>
  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 color=blue face="sans-serif"><u>http://www.ibm.com/developerworks/blogs/page/JohnBoyer</u></font></a><font size=2 face="sans-serif"><br>
  </font><font size=3><br>
  <br>
  <br>
  </font>
  <table width=100%>
  <tr valign=top>
  <td width=40%><font size=1 face="sans-serif"><b>&quot;Michael Kay&quot;
  &lt;mike@saxonica.com&gt;</b> <br>
  Sent by: www-forms-editor-request@w3.org</font><font size=3> </font>
  <p><font size=1 face="sans-serif">10/18/2007 01:53 AM</font><font size=3>
  </font>
  <td width=59%>
  <br>
  <table width=100%>
  <tr valign=top>
  <td width=11%>
  <div align=right><font size=1 face="sans-serif">To</font></div>
  <td width=88%><font size=1 face="sans-serif">&quot;'John Boyer'&quot; &lt;xforms-issues@mn.aptest.com&gt;</font><font size=3>
  </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;w3c-xml-query-wg@w3.org&gt;, &lt;www-forms-editor@w3.org&gt;</font><font size=3>
  </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: 7.10.4 (PR#147)</font></table>
  <br>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br><font size=3><br>
  <br>
  </font><tt><font size=2><br>
  <br>
  <br>
  Well, I'm clearly not going to persuade you, but it seems a very<br>
  short-sighted attitude to me.<br>
  <br>
  If the XForms specification doesn't support XPath 2.0 until 2010, then
  an<br>
  increasing number of vendors will support it unilaterally (some already
  do),<br>
  which means the coexistence and transition issues will be even worse.<br>
  <br>
  In any, case, the argument seems a bit like the millenium bug: we won't<br>
  worry about this problem because it will be three years before users notice<br>
  it.<br>
  <br>
  Michael Kay<br>
  <br>
  <br>
  &gt; -----Original Message-----<br>
  &gt; From: John Boyer [</font></tt><a href="mailto:xforms-issues@mn.aptest.com"><tt><font size=2 color=blue><u>mailto:xforms-issues@mn.aptest.com</u></font></tt></a><tt><font size=2>]
  <br>
  &gt; Sent: 18 October 2007 09:27<br>
  &gt; To: mike@saxonica.com<br>
  &gt; Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org<br>
  &gt; Subject: Re: 7.10.4 (PR#147)<br>
  &gt; <br>
  &gt; Hi Michael,<br>
  &gt; <br>
  &gt; I received your follow-up recommending that we add <br>
  &gt; seconds-from-1970() and deprecate seconds-from-dataTime() to <br>
  &gt; make future updating to XForms 2.0/XPath 2.0 easier.<br>
  &gt; <br>
  &gt; This only seems to add confusing complexities to XForms 1.1 <br>
  &gt; in order to make at best a minor improvement to the future <br>
  &gt; update capabilities. &nbsp;The update of 1.x content to XForms 2.0
  <br>
  &gt; should have much bigger issues than this.<br>
  &gt; It is also by no means clear that a form author undergoing <br>
  &gt; such a large update of content would even want to retain the <br>
  &gt; 1970 semantic anyway because the typical call of these <br>
  &gt; functions is to do date math and comparisons.<br>
  &gt; <br>
  &gt; Finally, it should be noted that the current estimated <br>
  &gt; (optimistic) timeframe for an XForms 2.0 recommendation is <br>
  &gt; the end of 2010.<br>
  &gt; <br>
  &gt; Best regards,<br>
  &gt; John Boyer<br>
  &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; &nbsp; &nbsp; L. The seconds-from-dateTime() function poses a
  <br>
  &gt; particular problem<br>
  &gt; &gt; &nbsp; &nbsp; because XPath 2.0 offers a function with the same
  name and<br>
  &gt; &gt; &nbsp; &nbsp; different semantics.<br>
  &gt; &gt; <br>
  &gt; &gt; &nbsp; &nbsp; You should define whether leap second are taken
  into <br>
  &gt; account, and<br>
  &gt; &gt; &nbsp; &nbsp; if so, specify how.<br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  <br>
  </font></tt><font size=3><br>
  </font>
  <br>
  --=_alternative 006DA7FF8825738E_=--
  

FOLLOWUP 6:

  From: "Michael Kay" <mike@saxonica.com>
  
  I would strongly suggest that you provide a synonym for this function
  (perhaps seconds-since-1970())and deprecate the old name, to make transition
  easier in 2.0. 
  
  Michael Kay
  
  > -----Original Message-----
  > From: Nick Van den Bleeken [mailto:xforms-issues@mn.aptest.com] 
  > Sent: 13 September 2007 08:57
  > To: mike@saxonica.com
  > Cc: w3c-xml-query-wg@w3.org
  > Subject: Re: 7.10.4 (PR#147)
  > 
  > Dear Michael,
  > 
  > The seconds-from-dateTime() function is a several-years-old 
  > XForms 1.0 function defined for use with XPath 1.0.
  > The semantic differences should probably be addressed in 
  > XForms 2.0 when we actually move to XPath 2.0.
  > 
  > Regarding leap seconds, we will add text that states that 
  > leap seconds are not supported.
  > 
  > Regards,
  > 
  > Nick Van den Bleeken
  > > 
  > > 
  > >     L. The seconds-from-dateTime() function poses a 
  > particular problem
  > >     because XPath 2.0 offers a function with the same name and
  > >     different semantics.
  > > 
  > >     You should define whether leap second are taken into 
  > account, and
  > >     if so, specify how.
  > > 
  > > 
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Michael,
  
  I received your follow-up recommending that we add seconds-from-1970() and
  deprecate seconds-from-dataTime() to make future updating to XForms 2.0/XPath
  2.0 easier.
  
  This only seems to add confusing complexities to XForms 1.1 in order to make at
  best a minor improvement to the future update capabilities.  The update of 1.x
  content to XForms 2.0 should have much bigger issues than this.
  It is also by no means clear that a form author undergoing such a large update
  of content would even want to retain the 1970 semantic anyway because the
  typical call of these functions is to do date math and comparisons.
  
  Finally, it should be noted that the current estimated (optimistic) timeframe
  for an XForms 2.0 recommendation is the end of 2010.
  
  Best regards,
  John Boyer
  
  > 
  > 
  >     L. The seconds-from-dateTime() function poses a particular problem
  >     because XPath 2.0 offers a function with the same name and
  >     different semantics.
  > 
  >     You should define whether leap second are taken into account, and
  >     if so, specify how.
  > 
  > 

REPLY 2:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Dear Michael,
  
  The seconds-from-dateTime() function is a several-years-old XForms 1.0 function
  defined for use with XPath 1.0.
  The semantic differences should probably be addressed in XForms 2.0 when we
  actually move to XPath 2.0.
  
  Regarding leap seconds, we will add text that states that leap seconds are not
  supported.
  
  Regards,
  
  Nick Van den Bleeken
  > 
  > 
  >     L. The seconds-from-dateTime() function poses a particular problem
  >     because XPath 2.0 offers a function with the same name and
  >     different semantics.
  > 
  >     You should define whether leap second are taken into account, and
  >     if so, specify how.
  > 
  > 

15.27 editorial: 7.11.1 The instance() Function

PROBLEM ID: 161

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

NOTES:

  Elliotte's email identified a section number and problem common to XForms 1.1
  and 1.0.  
  
  I replied that the problem was already fixed here:
  http://lists.w3.org/Archives/Public/www-forms-editor/2007Jul/0011.html
  
  He clarifies that he meant to report the problem on 1.0 here:
  http://lists.w3.org/Archives/Public/www-forms-editor/2007Jul/0012.html

ORIGINAL MESSAGE:

  From: "Elliotte Harold" <elharo@metalab.unc.edu>
  
  
  Although there's an existing erratum for 7.11.1 it doesn't seem to
  address this problem:
  
  
  "An XForms Model can contain more that one instance."
  
  -->
  
  "An XForms Model can contain more than one instance."
  
  that --> than
  
  
  -- 
  Elliotte Rusty Harold  elharo@metalab.unc.edu
  Java I/O 2nd Edition Just Published!
  http://www.cafeaulait.org/books/javaio2/
  http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Elliotte,
  
  Thank you.  This has been handled now.
  
  Best regards,
  John Boyer
  
  > 
  > Although there's an existing erratum for 7.11.1 it doesn't seem to
  > address this problem:
  > 
  > 
  > "An XForms Model can contain more that one instance."
  > 
  > -->
  > 
  > "An XForms Model can contain more than one instance."
  > 
  > that --> than
  > 
  > 
  > -- 
  > Elliotte Rusty Harold  elharo@metalab.unc.edu
  > Java I/O 2nd Edition Just Published!
  > http://www.cafeaulait.org/books/javaio2/
  > http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
  > 
  > 

15.28 [LC] 7.8.8 The random() Function

PROBLEM ID: 66

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

NOTES:

  we need the specify the interval of random

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#fn-random
  
  "This function generates and returns a uniformly distributed random or
  pseudorandom number between 0.0 and 1.0"
  
  I assume what is meant here is 0.0<=random()<1.0
  
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  This is now fixed.  Please see the editor's draft available from the Forms WG
  website.
  
  Thanks,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#fn-random
  > 
  > "This function generates and returns a uniformly distributed random or
  > pseudorandom number between 0.0 and 1.0"
  > 
  > I assume what is meant here is 0.0<=random()<1.0
  > 
  > 
  > 

15.29 LC: Minor consistency issue: "halt" vs. "stop"

PROBLEM ID: 34

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

NOTES:

  It is just an editorial change

ORIGINAL MESSAGE:

  From: "Erik Bruchez" <ebruchez@orbeon.com>
  
  
  All,
  
  This is really minor but easy to fix.
  
  The wording used to specify that XForms engine processing must stop is
  "halt processing" ("4.5 Error Indications") or "processing halts"
  (everywhere else).
  
  There is one exception in section "7.12 Extension Functions" where the
  wording is "stop processing".
  
  I recommend fixing 7.12 by changing from "[...] and stop processing by
  [...]" to "[...] and processing halts by [...]".
  
  -Erik
  
  -- 
  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  http://www.orbeon.com/
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Erik,
  
  You are right. We will update the spec accordingly. 
  
  Many thanks.
  
  Nick Van den Bleeken
  For the Forms WG
  
  > 
  > All,
  > 
  > This is really minor but easy to fix.
  > 
  > The wording used to specify that XForms engine processing must stop is
  > "halt processing" ("4.5 Error Indications") or "processing halts"
  > (everywhere else).
  > 
  > There is one exception in section "7.12 Extension Functions" where the
  > wording is "stop processing".
  > 
  > I recommend fixing 7.12 by changing from "[...] and stop processing by
  > [...]" to "[...] and processing halts by [...]".
  > 
  > -Erik
  > 
  > -- 
  > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
  > http://www.orbeon.com/
  > 
  > 

15.30 Section 7: hasFeature

PROBLEM ID: 156

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

NOTES:

  I think there is confusion about what hasFeature() is.  I do not think it is a
  function callable from XPath.
  As Mark B rightly pointed out, section 7.2 is in the wrong chapter, and it has
  been moved to the end of Chapter 4 in the editor's draft.
  
  I believe the return value should still be 1.0 because this appears to be the
  first version of the DOM interface.

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
  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  22) Section 7.2 - Shouldn't hasFeature return 1.1?  Otherwise how do I know
  if the processor handles 1.1 stuff?
  

REPLY 1:

  From: Nick Van den Bleeken <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  hasFeature returns 1.0 because it returning the version of the DOM interface and
  there is no new version (e.g.: 1.1) of the DOM interface in XForms 1.1.
  
  We also aren't going to add a 'getProcessorVersion()' function to the IDL
  because our interface doesn't contain any processor version dependent methods.
  
  Regards,
  
  Nick Van den Bleeken
  > 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
  > From: "Aaron Reed" <aaronr@us.ibm.com>
  > 
  > 22) Section 7.2 - Shouldn't hasFeature return 1.1?  Otherwise how do I know
  > if the processor handles 1.1 stuff?
  > 
  > 

15.31 [LC] 7.9.5 The hmac() Function

PROBLEM ID: 67

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

NOTES:

  drop alternatives of lower case keywords (e.g.: drop sha-256, SHA256, SHA-256
  variants of sha256)
  Only modestly substantive; no implementation experience or review is invalidated
  by dropping the keywords as all the possible hash algorithms are still
  represented

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#fn-hmac
  
  Why bother with all the alternatives for the parameter?
  
  MD5 is missing from the list.
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  The alternatives have been reduced to a single keyword per hash algorithm: MD5
  and SHA-1, SHA-256, SHA-384, and SHA-512.
  As part of that, MD5 was added (esp. since md5 was removed).
  
  Thanks,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#fn-hmac
  > 
  > Why bother with all the alternatives for the parameter?
  > 
  > MD5 is missing from the list.
  > 
  > 

15.32 [LC: editorial] 7.8.6 The power() Function

PROBLEM ID: 64

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

NOTES:

  Add example:
  
  power(2, 3)
  Returns 8

ORIGINAL MESSAGE:

  From: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
  
  
  http://www.w3.org/TR/xforms11/#fn-power
  
  Please give real values in examples, not just error cases, so people
  can check their understanding.
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Steven,
  
  This is done.  Please see the editor's draft from the Forms WG website.
  
  Thanks,
  John Boyer
  
  > 
  > http://www.w3.org/TR/xforms11/#fn-power
  > 
  > Please give real values in examples, not just error cases, so people
  > can check their understanding.
  > 
  > 

15.33 7.8.8

PROBLEM ID: 145

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

ORIGINAL MESSAGE:

  From: "Michael Kay" <mike@saxonica.com>
  
  
  
  
      J. The random() function poses semantic problems because it is not
      a pure function. Users of this function will have expectations, for
      example that the function call will not be moved out of a
      predicate, which the XPath formal semantics cannot guarantee.
  
      Functions that depend on anything beyond their parameters don't fit
      the design of XPath.
  
      This is a hard area. We're quite willing to work with you on
      designing this. (: We note that this function is new in XForms 1.1
      so there are no compatibility requirements here :)
  
  

FOLLOWUP 1:

  From: "Michael Kay" <mike@saxonica.com>
  
  Thanks for the thoughtful answer.
  
  I wasn't really concerned about stability of the environment across
  different XPath evaluations: I was thinking of stability within a single
  evaluation, for example the semantics of an expression such as
  
  for $i in 1 to 20 return random()
  
  The other functions that you mention have an explicit and formalized
  dependency on the dynamic context, which is either invariant for the
  evaluation of an XPath expression, or changes in a well-defined way (as with
  the context item, position, and size inside a predicate). This is not the
  case for your proposed random() function, and I can see implementations
  having considerable difficulty with expressions such as the one above:
  essentially, optimizers will have to special-case it, which means it may not
  be possible to implement it without changes to the core of the XPath engine.
  
  It's possible that in future the work on XQuery scripting extensions may be
  able to formalize the semantics of functions that have side-effects, but I
  think it would be unwise to anticipate that work for the sake of one
  function.
  
  I think you would be better off providing a function that returns a sequence
  of random numbers, along the lines of exslt:random(), defined here:
  
  http://www.exslt.org/random/index.html
  
  That function was designed after informed discussion of these issues in the
  community.
  
  Michael Kay
  http://www.saxonica.com/ 
  
  
  > -----Original Message-----
  > From: John Boyer [mailto:xforms-issues@mn.aptest.com] 
  > Sent: 24 October 2007 05:52
  > To: mike@saxonica.com
  > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
  > Subject: Re: 7.8.8 (PR#145)
  > 
  > Hi Michael,
  > 
  > The working group recognizes that there is a bit of a backlog 
  > of expectations about XPath, particularly in light of its use 
  > within XSLT.  Strictly speaking, there is nothing in the 
  > XPath 1.0 recommendation to suggest that extension functions 
  > are unable to rely on sources of information other than 
  > explicit parameters, and of course the implicit parameter of 
  > the data model containing the context node.
  > 
  > As a result, the issue extends beyond the particular function 
  > mentioned in your comment.  The same issue exists for other 
  > functions new to XForms 1.1 including the local-date(), 
  > local-dateTime(), context() and event() functions, but also, 
  > crucially, functions such as now(), instance(), index() and 
  > property() in 1.0. 
  > The 1.0 functions in particular have proven that XForms 
  > processors are able to
  > implement functions of this type, a necessary component for 
  > exiting CR.   The
  > new functions in 1.1, including the one you mentioned, do not 
  > extend the use of XPath in a fundamentally new way beyond the 
  > XForms 1.0 recommendation.
  > 
  > Perhaps of equal importance, XForms is a document format that 
  > is capable of containing both XPath expressions that operate 
  > over instance data and also performing mutations of the 
  > instance data.  Because a mutation can occur between 
  > virtually any two successive XPath evaluations, it happens 
  > that the types of optimizations you mentioned below are not 
  > possible for XForms.  Put another way, XPath functions do 
  > indeed rely on another data source not expressed in their
  > parameters:  the document data model.  Other language 
  > consumers of XPath may hold constant the input document data 
  > model, so that it appears that functions are only dependent 
  > on their parameters.  But in XForms, the data must be "filled 
  > in" by the user, so mutation of the document data model is 
  > unavoidable.  As a result, functions like id(), last(), 
  > count(), position() and even simple name tests are subject to 
  > change from one evaluation of a given XPath expression to the next.
  > 
  > For these reasons, the working group resolved to retain the 
  > functions defined in both XForms 1.0 and XForms 1.1.  As 
  > well, we do agree that it is necessary to have discussions 
  > with the XQuery group to gain a better understanding of how 
  > classic XPath optimization techniques are affected by issues 
  > like document
  > mutation in XForms.   In fact, one might regard our work on 
  > dependency lists and
  > the master dependency digraph that drives recalculation as 
  > examples of optimizations that might be more broadly 
  > applicable than just to XForms.
  > 
  > Thank you for your consideration of XForms.
  > 
  > Best regards,
  > John Boyer
  > 
  > > 
  > > 
  > > 
  > >     J. The random() function poses semantic problems 
  > because it is not
  > >     a pure function. Users of this function will have 
  > expectations, for
  > >     example that the function call will not be moved out of a
  > >     predicate, which the XPath formal semantics cannot guarantee.
  > > 
  > >     Functions that depend on anything beyond their 
  > parameters don't fit
  > >     the design of XPath.
  > > 
  > >     This is a hard area. We're quite willing to work with you on
  > >     designing this. (: We note that this function is new in 
  > XForms 1.1
  > >     so there are no compatibility requirements here :)
  > > 
  > > 
  > > 
  

FOLLOWUP 2:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 006EF9828825738E_=
  Content-Type: text/plain; charset="US-ASCII"
  
  Hi Michael,
  
  Could you please let us know what should be put on the final disposition 
  of this comment?
  Given the additional information about the XForms perspective, which 
  combines mutability with a batch processing view of XPaths, was convincing 
  enough that you would be willing to accept that the function in question 
  presents no special burden in our case, esp. in comparison to the 
  resulting ease of authoring.  Or would you prefer that we record a 
  disagree result, or a formal objection result.  Could you please let us 
  know by Monday since the current recorded result is 'No response' to the 
  end of the thread, but I would like a more definitive setting given the 
  work that has gone into this consideration.
  
  Thank you,
  John M. Boyer, Ph.D.
  STSM: Lotus Forms Architect and Researcher
  Chair, W3C Forms Working Group
  Workplace, Portal and Collaboration Software
  IBM Victoria Software Lab
  E-Mail: boyerj@ca.ibm.com 
  
  Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
  
  
  
  
  
  John Boyer/CanWest/IBM@IBMCA 
  Sent by: www-forms-editor-request@w3.org
  10/24/2007 09:21 AM
  
  To
  "Michael Kay" <mike@saxonica.com>
  cc
  w3c-xml-query-wg@w3.org, www-forms-editor@w3.org, 
  www-forms-editor-request@w3.org, "'John Boyer'" 
  <xforms-issues@mn.aptest.com>
  Subject
  RE: 7.8.8 (PR#145)
  
  
  
  
  
  
  
  Hi Michael, 
  
  Scripted loops in XForms live outside of the XPath expression language in 
  XForms. 
  
  Also, in XForms the form author's perspective is that when they make a 
  script change, then all calculations are performed.  The calculations are 
  separate XPaths, but it is a little like running them in a loop whose 
  order is determined by topological sorting.  The point is that in that 
  case, which is conceptually similar to the one you pointed out, I have 
  personally run a form that invoked now() twice-- in two separate XPaths-- 
  and the one second boundary was crossed between the two executions. 
  Similarly, UI refreshment is a time when there is the potential for a lot 
  of change at once based on event handlers for the dispatched UI events. 
  Again, these changes affect how succeeding XPaths will run even though the 
  full set of XPaths are viewed as a 'batch' from the author's perspective. 
  
  The point is that from XForms perspective, which combines DOM mutability 
  with 'batch' XPath processing, the particular function in question 
  presents no additional burden of care on the form author, nor 
  unfortunately is there any other way to introduce this required feature 
  that would not introduce the same burden of care on the form author. 
  
  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
  
  
  
  
  "Michael Kay" <mike@saxonica.com> 
  Sent by: www-forms-editor-request@w3.org 
  10/24/2007 02:35 AM 
  
  
  To
  "'John Boyer'" <xforms-issues@mn.aptest.com> 
  cc
  <w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org> 
  Subject
  RE: 7.8.8 (PR#145)
  
  
  
  
  
  
  
  
  
  Thanks for the thoughtful answer.
  
  I wasn't really concerned about stability of the environment across
  different XPath evaluations: I was thinking of stability within a single
  evaluation, for example the semantics of an expression such as
  
  for $i in 1 to 20 return random()
  
  The other functions that you mention have an explicit and formalized
  dependency on the dynamic context, which is either invariant for the
  evaluation of an XPath expression, or changes in a well-defined way (as 
  with
  the context item, position, and size inside a predicate). This is not the
  case for your proposed random() function, and I can see implementations
  having considerable difficulty with expressions such as the one above:
  essentially, optimizers will have to special-case it, which means it may 
  not
  be possible to implement it without changes to the core of the XPath 
  engine.
  
  It's possible that in future the work on XQuery scripting extensions may 
  be
  able to formalize the semantics of functions that have side-effects, but I
  think it would be unwise to anticipate that work for the sake of one
  function.
  
  I think you would be better off providing a function that returns a 
  sequence
  of random numbers, along the lines of exslt:random(), defined here:
  
  http://www.exslt.org/random/index.html
  
  That function was designed after informed discussion of these issues in 
  the
  community.
  
  Michael Kay
  http://www.saxonica.com/ 
  
  
  > -----Original Message-----
  > From: John Boyer [mailto:xforms-issues@mn.aptest.com] 
  > Sent: 24 October 2007 05:52
  > To: mike@saxonica.com
  > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
  > Subject: Re: 7.8.8 (PR#145)
  > 
  > Hi Michael,
  > 
  > The working group recognizes that there is a bit of a backlog 
  > of expectations about XPath, particularly in light of its use 
  > within XSLT.  Strictly speaking, there is nothing in the 
  > XPath 1.0 recommendation to suggest that extension functions 
  > are unable to rely on sources of information other than 
  > explicit parameters, and of course the implicit parameter of 
  > the data model containing the context node.
  > 
  > As a result, the issue extends beyond the particular function 
  > mentioned in your comment.  The same issue exists for other 
  > functions new to XForms 1.1 including the local-date(), 
  > local-dateTime(), context() and event() functions, but also, 
  > crucially, functions such as now(), instance(), index() and 
  > property() in 1.0. 
  > The 1.0 functions in particular have proven that XForms 
  > processors are able to
  > implement functions of this type, a necessary component for 
  > exiting CR.   The
  > new functions in 1.1, including the one you mentioned, do not 
  > extend the use of XPath in a fundamentally new way beyond the 
  > XForms 1.0 recommendation.
  > 
  > Perhaps of equal importance, XForms is a document format that 
  > is capable of containing both XPath expressions that operate 
  > over instance data and also performing mutations of the 
  > instance data.  Because a mutation can occur between 
  > virtually any two successive XPath evaluations, it happens 
  > that the types of optimizations you mentioned below are not 
  > possible for XForms.  Put another way, XPath functions do 
  > indeed rely on another data source not expressed in their
  > parameters:  the document data model.  Other language 
  > consumers of XPath may hold constant the input document data 
  > model, so that it appears that functions are only dependent 
  > on their parameters.  But in XForms, the data must be "filled 
  > in" by the user, so mutation of the document data model is 
  > unavoidable.  As a result, functions like id(), last(), 
  > count(), position() and even simple name tests are subject to 
  > change from one evaluation of a given XPath expression to the next.
  > 
  > For these reasons, the working group resolved to retain the 
  > functions defined in both XForms 1.0 and XForms 1.1.  As 
  > well, we do agree that it is necessary to have discussions 
  > with the XQuery group to gain a better understanding of how 
  > classic XPath optimization techniques are affected by issues 
  > like document
  > mutation in XForms.   In fact, one might regard our work on 
  > dependency lists and
  > the master dependency digraph that drives recalculation as 
  > examples of optimizations that might be more broadly 
  > applicable than just to XForms.
  > 
  > Thank you for your consideration of XForms.
  > 
  > Best regards,
  > John Boyer
  > 
  > > 
  > > 
  > > 
  > >     J. The random() function poses semantic problems 
  > because it is not
  > >     a pure function. Users of this function will have 
  > expectations, for
  > >     example that the function call will not be moved out of a
  > >     predicate, which the XPath formal semantics cannot guarantee.
  > > 
  > >     Functions that depend on anything beyond their 
  > parameters don't fit
  > >     the design of XPath.
  > > 
  > >     This is a hard area. We're quite willing to work with you on
  > >     designing this. (: We note that this function is new in 
  > XForms 1.1
  > >     so there are no compatibility requirements here :)
  > > 
  > > 
  > > 
  
  
  
  
  --=_alternative 006EF9828825738E_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <br><font size=2 face="sans-serif">Hi Michael,</font>
  <br>
  <br><font size=2 face="sans-serif">Could you please let us know what should
  be put on the final disposition of this comment?</font>
  <br><font size=2 face="sans-serif">Given the additional information about
  the XForms perspective, which combines mutability with a batch processing
  view of XPaths, was convincing enough that you would be willing to accept
  that the function in question presents no special burden in our case, esp.
  in comparison to the resulting ease of authoring. &nbsp;Or would you prefer
  that we record a disagree result, or a formal objection result. &nbsp;Could
  you please let us know by Monday since the current recorded result is 'No
  response' to the end of the thread, but I would like a more definitive
  setting given the work that has gone into this consideration.</font>
  <br>
  <br><font size=2 face="sans-serif">Thank you,</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>John Boyer/CanWest/IBM@IBMCA</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">10/24/2007 09:21 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;Michael Kay&quot; &lt;mike@saxonica.com&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">w3c-xml-query-wg@w3.org, www-forms-editor@w3.org,
  www-forms-editor-request@w3.org, &quot;'John Boyer'&quot; &lt;xforms-issues@mn.aptest.com&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: 7.8.8 (PR#145)</font></table>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br>
  <br>
  <br><font size=2 face="sans-serif"><br>
  Hi Michael,</font><font size=3> <br>
  </font><font size=2 face="sans-serif"><br>
  Scripted loops in XForms live outside of the XPath expression language
  in XForms.</font><font size=3> <br>
  </font><font size=2 face="sans-serif"><br>
  Also, in XForms the form author's perspective is that when they make a
  script change, then all calculations are performed. &nbsp;The calculations
  are separate XPaths, but it is a little like running them in a loop whose
  order is determined by topological sorting. &nbsp;The point is that in
  that case, which is conceptually similar to the one you pointed out, I
  have personally run a form that invoked now() twice-- in two separate XPaths--
  and the one second boundary was crossed between the two executions. &nbsp;Similarly,
  UI refreshment is a time when there is the potential for a lot of change
  at once based on event handlers for the dispatched UI events. &nbsp;Again,
  these changes affect how succeeding XPaths will run even though the full
  set of XPaths are viewed as a 'batch' from the author's perspective.</font><font size=3>
  <br>
  </font><font size=2 face="sans-serif"><br>
  The point is that from XForms perspective, which combines DOM mutability
  with 'batch' XPath processing, the particular function in question presents
  no additional burden of care on the form author, nor unfortunately is there
  any other way to introduce this required feature that would not introduce
  the same burden of care on the form author.</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>
  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 color=blue face="sans-serif"><u>http://www.ibm.com/developerworks/blogs/page/JohnBoyer</u></font></a><font size=2 face="sans-serif"><br>
  </font><font size=3><br>
  <br>
  <br>
  </font>
  <table width=100%>
  <tr valign=top>
  <td width=40%><font size=1 face="sans-serif"><b>&quot;Michael Kay&quot;
  &lt;mike@saxonica.com&gt;</b> <br>
  Sent by: www-forms-editor-request@w3.org</font><font size=3> </font>
  <p><font size=1 face="sans-serif">10/24/2007 02:35 AM</font><font size=3>
  </font>
  <td width=59%>
  <br>
  <table width=100%>
  <tr valign=top>
  <td width=11%>
  <div align=right><font size=1 face="sans-serif">To</font></div>
  <td width=88%><font size=1 face="sans-serif">&quot;'John Boyer'&quot; &lt;xforms-issues@mn.aptest.com&gt;</font><font size=3>
  </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;w3c-xml-query-wg@w3.org&gt;, &lt;www-forms-editor@w3.org&gt;</font><font size=3>
  </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: 7.8.8 (PR#145)</font></table>
  <br>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br><font size=3><br>
  <br>
  </font><tt><font size=2><br>
  <br>
  Thanks for the thoughtful answer.<br>
  <br>
  I wasn't really concerned about stability of the environment across<br>
  different XPath evaluations: I was thinking of stability within a single<br>
  evaluation, for example the semantics of an expression such as<br>
  <br>
  for $i in 1 to 20 return random()<br>
  <br>
  The other functions that you mention have an explicit and formalized<br>
  dependency on the dynamic context, which is either invariant for the<br>
  evaluation of an XPath expression, or changes in a well-defined way (as
  with<br>
  the context item, position, and size inside a predicate). This is not the<br>
  case for your proposed random() function, and I can see implementations<br>
  having considerable difficulty with expressions such as the one above:<br>
  essentially, optimizers will have to special-case it, which means it may
  not<br>
  be possible to implement it without changes to the core of the XPath engine.<br>
  <br>
  It's possible that in future the work on XQuery scripting extensions may
  be<br>
  able to formalize the semantics of functions that have side-effects, but
  I<br>
  think it would be unwise to anticipate that work for the sake of one<br>
  function.<br>
  <br>
  I think you would be better off providing a function that returns a sequence<br>
  of random numbers, along the lines of exslt:random(), defined here:<br>
  </font></tt><font size=3 color=blue><u><br>
  </u></font><a href=http://www.exslt.org/random/index.html><tt><font size=2 color=blue><u>http://www.exslt.org/random/index.html</u></font></tt></a><tt><font size=2><br>
  <br>
  That function was designed after informed discussion of these issues in
  the<br>
  community.<br>
  <br>
  Michael Kay</font></tt><font size=3 color=blue><u><br>
  </u></font><a href=http://www.saxonica.com/><tt><font size=2 color=blue><u>http://www.saxonica.com/</u></font></tt></a><tt><font size=2>
  <br>
  <br>
  <br>
  &gt; -----Original Message-----<br>
  &gt; From: John Boyer [</font></tt><a href="mailto:xforms-issues@mn.aptest.com"><tt><font size=2 color=blue><u>mailto:xforms-issues@mn.aptest.com</u></font></tt></a><tt><font size=2>]
  <br>
  &gt; Sent: 24 October 2007 05:52<br>
  &gt; To: mike@saxonica.com<br>
  &gt; Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org<br>
  &gt; Subject: Re: 7.8.8 (PR#145)<br>
  &gt; <br>
  &gt; Hi Michael,<br>
  &gt; <br>
  &gt; The working group recognizes that there is a bit of a backlog <br>
  &gt; of expectations about XPath, particularly in light of its use <br>
  &gt; within XSLT. &nbsp;Strictly speaking, there is nothing in the <br>
  &gt; XPath 1.0 recommendation to suggest that extension functions <br>
  &gt; are unable to rely on sources of information other than <br>
  &gt; explicit parameters, and of course the implicit parameter of <br>
  &gt; the data model containing the context node.<br>
  &gt; <br>
  &gt; As a result, the issue extends beyond the particular function <br>
  &gt; mentioned in your comment. &nbsp;The same issue exists for other <br>
  &gt; functions new to XForms 1.1 including the local-date(), <br>
  &gt; local-dateTime(), context() and event() functions, but also, <br>
  &gt; crucially, functions such as now(), instance(), index() and <br>
  &gt; property() in 1.0. <br>
  &gt; The 1.0 functions in particular have proven that XForms <br>
  &gt; processors are able to<br>
  &gt; implement functions of this type, a necessary component for <br>
  &gt; exiting CR. &nbsp; The<br>
  &gt; new functions in 1.1, including the one you mentioned, do not <br>
  &gt; extend the use of XPath in a fundamentally new way beyond the <br>
  &gt; XForms 1.0 recommendation.<br>
  &gt; <br>
  &gt; Perhaps of equal importance, XForms is a document format that <br>
  &gt; is capable of containing both XPath expressions that operate <br>
  &gt; over instance data and also performing mutations of the <br>
  &gt; instance data. &nbsp;Because a mutation can occur between <br>
  &gt; virtually any two successive XPath evaluations, it happens <br>
  &gt; that the types of optimizations you mentioned below are not <br>
  &gt; possible for XForms. &nbsp;Put another way, XPath functions do <br>
  &gt; indeed rely on another data source not expressed in their<br>
  &gt; parameters: &nbsp;the document data model. &nbsp;Other language <br>
  &gt; consumers of XPath may hold constant the input document data <br>
  &gt; model, so that it appears that functions are only dependent <br>
  &gt; on their parameters. &nbsp;But in XForms, the data must be &quot;filled
  <br>
  &gt; in&quot; by the user, so mutation of the document data model is <br>
  &gt; unavoidable. &nbsp;As a result, functions like id(), last(), <br>
  &gt; count(), position() and even simple name tests are subject to <br>
  &gt; change from one evaluation of a given XPath expression to the next.<br>
  &gt; <br>
  &gt; For these reasons, the working group resolved to retain the <br>
  &gt; functions defined in both XForms 1.0 and XForms 1.1. &nbsp;As <br>
  &gt; well, we do agree that it is necessary to have discussions <br>
  &gt; with the XQuery group to gain a better understanding of how <br>
  &gt; classic XPath optimization techniques are affected by issues <br>
  &gt; like document<br>
  &gt; mutation in XForms. &nbsp; In fact, one might regard our work on <br>
  &gt; dependency lists and<br>
  &gt; the master dependency digraph that drives recalculation as <br>
  &gt; examples of optimizations that might be more broadly <br>
  &gt; applicable than just to XForms.<br>
  &gt; <br>
  &gt; Thank you for your consideration of XForms.<br>
  &gt; <br>
  &gt; Best regards,<br>
  &gt; John Boyer<br>
  &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; &nbsp; &nbsp; J. The random() function poses semantic problems
  <br>
  &gt; because it is not<br>
  &gt; &gt; &nbsp; &nbsp; a pure function. Users of this function will have
  <br>
  &gt; expectations, for<br>
  &gt; &gt; &nbsp; &nbsp; example that the function call will not be moved
  out of a<br>
  &gt; &gt; &nbsp; &nbsp; predicate, which the XPath formal semantics cannot
  guarantee.<br>
  &gt; &gt; <br>
  &gt; &gt; &nbsp; &nbsp; Functions that depend on anything beyond their
  <br>
  &gt; parameters don't fit<br>
  &gt; &gt; &nbsp; &nbsp; the design of XPath.<br>
  &gt; &gt; <br>
  &gt; &gt; &nbsp; &nbsp; This is a hard area. We're quite willing to work
  with you on<br>
  &gt; &gt; &nbsp; &nbsp; designing this. (: We note that this function is
  new in <br>
  &gt; XForms 1.1<br>
  &gt; &gt; &nbsp; &nbsp; so there are no compatibility requirements here
  :)<br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  <br>
  </font></tt><font size=3><br>
  </font>
  <br>
  --=_alternative 006EF9828825738E_=--
  

FOLLOWUP 3:

  From: w3c-xml-query-wg-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 Michael,
  
  The working group recognizes that there is a bit of a backlog of expectations
  about XPath, particularly in light of its use within XSLT.  Strictly speaking,
  there is nothing in the XPath 1.0 recommendation to suggest that extension
  functions are unable to rely on sources of information other than explicit
  parameters, and of course the implicit parameter of the data model containing
  the context node.
  
  As a result, the issue extends beyond the particular function mentioned in your
  comment.  The same issue exists for other functions new to XForms 1.1 including
  the local-date(), local-dateTime(), context() and event() functions, but also,
  crucially, functions such as now(), instance(), index() and property() in 1.0. 
  The 1.0 functions in particular have proven that XForms processors are able to
  implement functions of this type, a necessary component for exiting CR.   The
  new functions in 1.1, including the one you mentioned, do not extend the use of
  XPath in a fundamentally new way beyond the XForms 1.0 recommendation.
  
  Perhaps of equal importance, XForms is a document format that is capable of
  containing both XPath expressions that operate over instance data and also
  performing mutations of the instance data.  Because a mutation can occur between
  virtually any two successive XPath evaluations, it happens that the types of
  optimizations you mentioned below are not possible for XForms.  Put another way,
  XPath functions do indeed rely on another data source not expressed in their
  parameters:  the document data model.  Other language consumers of XPath may
  hold constant the input document data model, so that it appears that functions
  are only dependent on their parameters.  But in XForms, the data must be "filled
  in" by the user, so mutation of the document data model is unavoidable.  As a
  result, functions like id(), last(), count(), position() and even simple name
  tests are subject to change from one evaluation of a given XPath expression to
  the next.
  
  For these reasons, the working group resolved to retain the functions defined in
  both XForms 1.0 and XForms 1.1.  As well, we do agree that it is necessary to
  have discussions with the XQuery group to gain a better understanding of how
  classic XPath optimization techniques are affected by issues like document
  mutation in XForms.   In fact, one might regard our work on dependency lists and
  the master dependency digraph that drives recalculation as examples of
  optimizations that might be more broadly applicable than just to XForms.
  
  Thank you for your consideration of XForms.
  
  Best regards,
  John Boyer
  
  > 
  > 
  > 
  >     J. The random() function poses semantic problems because it is not
  >     a pure function. Users of this function will have expectations, for
  >     example that the function call will not be moved out of a
  >     predicate, which the XPath formal semantics cannot guarantee.
  > 
  >     Functions that depend on anything beyond their parameters don't fit
  >     the design of XPath.
  > 
  >     This is a hard area. We're quite willing to work with you on
  >     designing this. (: We note that this function is new in XForms 1.1
  >     so there are no compatibility requirements here :)
  > 
  > 
  > 
  

FOLLOWUP 4:

  From: John Boyer <boyerj@ca.ibm.com>
  
  This is a multipart message in MIME format.
  --=_alternative 0059EECB8825737E_=
  Content-Type: text/plain; charset="US-ASCII"
  
  Hi Michael,
  
  Scripted loops in XForms live outside of the XPath expression language in 
  XForms.
  
  Also, in XForms the form author's perspective is that when they make a 
  script change, then all calculations are performed.  The calculations are 
  separate XPaths, but it is a little like running them in a loop whose 
  order is determined by topological sorting.  The point is that in that 
  case, which is conceptually similar to the one you pointed out, I have 
  personally run a form that invoked now() twice-- in two separate XPaths-- 
  and the one second boundary was crossed between the two executions. 
  Similarly, UI refreshment is a time when there is the potential for a lot 
  of change at once based on event handlers for the dispatched UI events. 
  Again, these changes affect how succeeding XPaths will run even though the 
  full set of XPaths are viewed as a 'batch' from the author's perspective.
  
  The point is that from XForms perspective, which combines DOM mutability 
  with 'batch' XPath processing, the particular function in question 
  presents no additional burden of care on the form author, nor 
  unfortunately is there any other way to introduce this required feature 
  that would not introduce the same burden of care on the form author.
  
  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
  
  
  
  
  
  "Michael Kay" <mike@saxonica.com> 
  Sent by: www-forms-editor-request@w3.org
  10/24/2007 02:35 AM
  
  To
  "'John Boyer'" <xforms-issues@mn.aptest.com>
  cc
  <w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org>
  Subject
  RE: 7.8.8 (PR#145)
  
  
  
  
  
  
  
  Thanks for the thoughtful answer.
  
  I wasn't really concerned about stability of the environment across
  different XPath evaluations: I was thinking of stability within a single
  evaluation, for example the semantics of an expression such as
  
  for $i in 1 to 20 return random()
  
  The other functions that you mention have an explicit and formalized
  dependency on the dynamic context, which is either invariant for the
  evaluation of an XPath expression, or changes in a well-defined way (as 
  with
  the context item, position, and size inside a predicate). This is not the
  case for your proposed random() function, and I can see implementations
  having considerable difficulty with expressions such as the one above:
  essentially, optimizers will have to special-case it, which means it may 
  not
  be possible to implement it without changes to the core of the XPath 
  engine.
  
  It's possible that in future the work on XQuery scripting extensions may 
  be
  able to formalize the semantics of functions that have side-effects, but I
  think it would be unwise to anticipate that work for the sake of one
  function.
  
  I think you would be better off providing a function that returns a 
  sequence
  of random numbers, along the lines of exslt:random(), defined here:
  
  http://www.exslt.org/random/index.html
  
  That function was designed after informed discussion of these issues in 
  the
  community.
  
  Michael Kay
  http://www.saxonica.com/ 
  
  
  > -----Original Message-----
  > From: John Boyer [mailto:xforms-issues@mn.aptest.com] 
  > Sent: 24 October 2007 05:52
  > To: mike@saxonica.com
  > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org
  > Subject: Re: 7.8.8 (PR#145)
  > 
  > Hi Michael,
  > 
  > The working group recognizes that there is a bit of a backlog 
  > of expectations about XPath, particularly in light of its use 
  > within XSLT.  Strictly speaking, there is nothing in the 
  > XPath 1.0 recommendation to suggest that extension functions 
  > are unable to rely on sources of information other than 
  > explicit parameters, and of course the implicit parameter of 
  > the data model containing the context node.
  > 
  > As a result, the issue extends beyond the particular function 
  > mentioned in your comment.  The same issue exists for other 
  > functions new to XForms 1.1 including the local-date(), 
  > local-dateTime(), context() and event() functions, but also, 
  > crucially, functions such as now(), instance(), index() and 
  > property() in 1.0. 
  > The 1.0 functions in particular have proven that XForms 
  > processors are able to
  > implement functions of this type, a necessary component for 
  > exiting CR.   The
  > new functions in 1.1, including the one you mentioned, do not 
  > extend the use of XPath in a fundamentally new way beyond the 
  > XForms 1.0 recommendation.
  > 
  > Perhaps of equal importance, XForms is a document format that 
  > is capable of containing both XPath expressions that operate 
  > over instance data and also performing mutations of the 
  > instance data.  Because a mutation can occur between 
  > virtually any two successive XPath evaluations, it happens 
  > that the types of optimizations you mentioned below are not 
  > possible for XForms.  Put another way, XPath functions do 
  > indeed rely on another data source not expressed in their
  > parameters:  the document data model.  Other language 
  > consumers of XPath may hold constant the input document data 
  > model, so that it appears that functions are only dependent 
  > on their parameters.  But in XForms, the data must be "filled 
  > in" by the user, so mutation of the document data model is 
  > unavoidable.  As a result, functions like id(), last(), 
  > count(), position() and even simple name tests are subject to 
  > change from one evaluation of a given XPath expression to the next.
  > 
  > For these reasons, the working group resolved to retain the 
  > functions defined in both XForms 1.0 and XForms 1.1.  As 
  > well, we do agree that it is necessary to have discussions 
  > with the XQuery group to gain a better understanding of how 
  > classic XPath optimization techniques are affected by issues 
  > like document
  > mutation in XForms.   In fact, one might regard our work on 
  > dependency lists and
  > the master dependency digraph that drives recalculation as 
  > examples of optimizations that might be more broadly 
  > applicable than just to XForms.
  > 
  > Thank you for your consideration of XForms.
  > 
  > Best regards,
  > John Boyer
  > 
  > > 
  > > 
  > > 
  > >     J. The random() function poses semantic problems 
  > because it is not
  > >     a pure function. Users of this function will have 
  > expectations, for
  > >     example that the function call will not be moved out of a
  > >     predicate, which the XPath formal semantics cannot guarantee.
  > > 
  > >     Functions that depend on anything beyond their 
  > parameters don't fit
  > >     the design of XPath.
  > > 
  > >     This is a hard area. We're quite willing to work with you on
  > >     designing this. (: We note that this function is new in 
  > XForms 1.1
  > >     so there are no compatibility requirements here :)
  > > 
  > > 
  > > 
  
  
  
  
  --=_alternative 0059EECB8825737E_=
  Content-Type: text/html; charset="US-ASCII"
  
  
  <br><font size=2 face="sans-serif">Hi Michael,</font>
  <br>
  <br><font size=2 face="sans-serif">Scripted loops in XForms live outside
  of the XPath expression language in XForms.</font>
  <br>
  <br><font size=2 face="sans-serif">Also, in XForms the form author's perspective
  is that when they make a script change, then all calculations are performed.
  &nbsp;The calculations are separate XPaths, but it is a little like running
  them in a loop whose order is determined by topological sorting. &nbsp;The
  point is that in that case, which is conceptually similar to the one you
  pointed out, I have personally run a form that invoked now() twice-- in
  two separate XPaths-- and the one second boundary was crossed between the
  two executions. &nbsp;Similarly, UI refreshment is a time when there is
  the potential for a lot of change at once based on event handlers for the
  dispatched UI events. &nbsp;Again, these changes affect how succeeding
  XPaths will run even though the full set of XPaths are viewed as a 'batch'
  from the author's perspective.</font>
  <br>
  <br><font size=2 face="sans-serif">The point is that from XForms perspective,
  which combines DOM mutability with 'batch' XPath processing, the particular
  function in question presents no additional burden of care on the form
  author, nor unfortunately is there any other way to introduce this required
  feature that would not introduce the same burden of care on the form author.</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>
  <br>
  <br>
  <br>
  <table width=100%>
  <tr valign=top>
  <td width=40%><font size=1 face="sans-serif"><b>&quot;Michael Kay&quot;
  &lt;mike@saxonica.com&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">10/24/2007 02:35 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;</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;w3c-xml-query-wg@w3.org&gt;, &lt;www-forms-editor@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: 7.8.8 (PR#145)</font></table>
  <br>
  <table>
  <tr valign=top>
  <td>
  <td></table>
  <br></table>
  <br>
  <br>
  <br><tt><font size=2><br>
  Thanks for the thoughtful answer.<br>
  <br>
  I wasn't really concerned about stability of the environment across<br>
  different XPath evaluations: I was thinking of stability within a single<br>
  evaluation, for example the semantics of an expression such as<br>
  <br>
  for $i in 1 to 20 return random()<br>
  <br>
  The other functions that you mention have an explicit and formalized<br>
  dependency on the dynamic context, which is either invariant for the<br>
  evaluation of an XPath expression, or changes in a well-defined way (as
  with<br>
  the context item, position, and size inside a predicate). This is not the<br>
  case for your proposed random() function, and I can see implementations<br>
  having considerable difficulty with expressions such as the one above:<br>
  essentially, optimizers will have to special-case it, which means it may
  not<br>
  be possible to implement it without changes to the core of the XPath engine.<br>
  <br>
  It's possible that in future the work on XQuery scripting extensions may
  be<br>
  able to formalize the semantics of functions that have side-effects, but
  I<br>
  think it would be unwise to anticipate that work for the sake of one<br>
  function.<br>
  <br>
  I think you would be better off providing a function that returns a sequence<br>
  of random numbers, along the lines of exslt:random(), defined here:<br>
  <br>
  </font></tt><a href=http://www.exslt.org/random/index.html><tt><font size=2>http://www.exslt.org/random/index.html</font></tt></a><tt><font size=2><br>
  <br>
  That function was designed after informed discussion of these issues in
  the<br>
  community.<br>
  <br>
  Michael Kay<br>
  </font></tt><a href=http://www.saxonica.com/><tt><font size=2>http://www.saxonica.com/</font></tt></a><tt><font size=2>
  <br>
  <br>
  <br>
  &gt; -----Original Message-----<br>
  &gt; From: John Boyer [</font></tt><a href="mailto:xforms-issues@mn.aptest.com"><tt><font size=2>mailto:xforms-issues@mn.aptest.com</font></tt></a><tt><font size=2>]
  <br>
  &gt; Sent: 24 October 2007 05:52<br>
  &gt; To: mike@saxonica.com<br>
  &gt; Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org<br>
  &gt; Subject: Re: 7.8.8 (PR#145)<br>
  &gt; <br>
  &gt; Hi Michael,<br>
  &gt; <br>
  &gt; The working group recognizes that there is a bit of a backlog <br>
  &gt; of expectations about XPath, particularly in light of its use <br>
  &gt; within XSLT. &nbsp;Strictly speaking, there is nothing in the <br>
  &gt; XPath 1.0 recommendation to suggest that extension functions <br>
  &gt; are unable to rely on sources of information other than <br>
  &gt; explicit parameters, and of course the implicit parameter of <br>
  &gt; the data model containing the context node.<br>
  &gt; <br>
  &gt; As a result, the issue extends beyond the particular function <br>
  &gt; mentioned in your comment. &nbsp;The same issue exists for other <br>
  &gt; functions new to XForms 1.1 including the local-date(), <br>
  &gt; local-dateTime(), context() and event() functions, but also, <br>
  &gt; crucially, functions such as now(), instance(), index() and <br>
  &gt; property() in 1.0. <br>
  &gt; The 1.0 functions in particular have proven that XForms <br>
  &gt; processors are able to<br>
  &gt; implement functions of this type, a necessary component for <br>
  &gt; exiting CR. &nbsp; The<br>
  &gt; new functions in 1.1, including the one you mentioned, do not <br>
  &gt; extend the use of XPath in a fundamentally new way beyond the <br>
  &gt; XForms 1.0 recommendation.<br>
  &gt; <br>
  &gt; Perhaps of equal importance, XForms is a document format that <br>
  &gt; is capable of containing both XPath expressions that operate <br>
  &gt; over instance data and also performing mutations of the <br>
  &gt; instance data. &nbsp;Because a mutation can occur between <br>
  &gt; virtually any two successive XPath evaluations, it happens <br>
  &gt; that the types of optimizations you mentioned below are not <br>
  &gt; possible for XForms. &nbsp;Put another way, XPath functions do <br>
  &gt; indeed rely on another data source not expressed in their<br>
  &gt; parameters: &nbsp;the document data model. &nbsp;Other language <br>
  &gt; consumers of XPath may hold constant the input document data <br>
  &gt; model, so that it appears that functions are only dependent <br>
  &gt; on their parameters. &nbsp;But in XForms, the data must be &quot;filled
  <br>
  &gt; in&quot; by the user, so mutation of the document data model is <br>
  &gt; unavoidable. &nbsp;As a result, functions like id(), last(), <br>
  &gt; count(), position() and even simple name tests are subject to <br>
  &gt; change from one evaluation of a given XPath expression to the next.<br>
  &gt; <br>
  &gt; For these reasons, the working group resolved to retain the <br>
  &gt; functions defined in both XForms 1.0 and XForms 1.1. &nbsp;As <br>
  &gt; well, we do agree that it is necessary to have discussions <br>
  &gt; with the XQuery group to gain a better understanding of how <br>
  &gt; classic XPath optimization techniques are affected by issues <br>
  &gt; like document<br>
  &gt; mutation in XForms. &nbsp; In fact, one might regard our work on <br>
  &gt; dependency lists and<br>
  &gt; the master dependency digraph that drives recalculation as <br>
  &gt; examples of optimizations that might be more broadly <br>
  &gt; applicable than just to XForms.<br>
  &gt; <br>
  &gt; Thank you for your consideration of XForms.<br>
  &gt; <br>
  &gt; Best regards,<br>
  &gt; John Boyer<br>
  &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; &nbsp; &nbsp; J. The random() function poses semantic problems
  <br>
  &gt; because it is not<br>
  &gt; &gt; &nbsp; &nbsp; a pure function. Users of this function will have
  <br>
  &gt; expectations, for<br>
  &gt; &gt; &nbsp; &nbsp; example that the function call will not be moved
  out of a<br>
  &gt; &gt; &nbsp; &nbsp; predicate, which the XPath formal semantics cannot
  guarantee.<br>
  &gt; &gt; <br>
  &gt; &gt; &nbsp; &nbsp; Functions that depend on anything beyond their
  <br>
  &gt; parameters don't fit<br>
  &gt; &gt; &nbsp; &nbsp; the design of XPath.<br>
  &gt; &gt; <br>
  &gt; &gt; &nbsp; &nbsp; This is a hard area. We're quite willing to work
  with you on<br>
  &gt; &gt; &nbsp; &nbsp; designing this. (: We note that this function is
  new in <br>
  &gt; XForms 1.1<br>
  &gt; &gt; &nbsp; &nbsp; so there are no compatibility requirements here
  :)<br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  &gt; &gt; <br>
  <br>
  <br>
  </font></tt>
  <br>
  --=_alternative 0059EECB8825737E_=--
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Michael,
  
  The working group recognizes that there is a bit of a backlog of expectations
  about XPath, particularly in light of its use within XSLT.  Strictly speaking,
  there is nothing in the XPath 1.0 recommendation to suggest that extension
  functions are unable to rely on sources of information other than explicit
  parameters, and of course the implicit parameter of the data model containing
  the context node.
  
  As a result, the issue extends beyond the particular function mentioned in your
  comment.  The same issue exists for other functions new to XForms 1.1 including
  the local-date(), local-dateTime(), context() and event() functions, but also,
  crucially, functions such as now(), instance(), index() and property() in 1.0. 
  The 1.0 functions in particular have proven that XForms processors are able to
  implement functions of this type, a necessary component for exiting CR.   The
  new functions in 1.1, including the one you mentioned, do not extend the use of
  XPath in a fundamentally new way beyond the XForms 1.0 recommendation.
  
  Perhaps of equal importance, XForms is a document format that is capable of
  containing both XPath expressions that operate over instance data and also
  performing mutations of the instance data.  Because a mutation can occur between
  virtually any two successive XPath evaluations, it happens that the types of
  optimizations you mentioned below are not possible for XForms.  Put another way,
  XPath functions do indeed rely on another data source not expressed in their
  parameters:  the document data model.  Other language consumers of XPath may
  hold constant the input document data model, so that it appears that functions
  are only dependent on their parameters.  But in XForms, the data must be "filled
  in" by the user, so mutation of the document data model is unavoidable.  As a
  result, functions like id(), last(), count(), position() and even simple name
  tests are subject to change from one evaluation of a given XPath expression to
  the next.
  
  For these reasons, the working group resolved to retain the functions defined in
  both XForms 1.0 and XForms 1.1.  As well, we do agree that it is necessary to
  have discussions with the XQuery group to gain a better understanding of how
  classic XPath optimization techniques are affected by issues like document
  mutation in XForms.   In fact, one might regard our work on dependency lists and
  the master dependency digraph that drives recalculation as examples of
  optimizations that might be more broadly applicable than just to XForms.
  
  Thank you for your consideration of XForms.
  
  Best regards,
  John Boyer
  
  > 
  > 
  > 
  >     J. The random() function poses semantic problems because it is not
  >     a pure function. Users of this function will have expectations, for
  >     example that the function call will not be moved out of a
  >     predicate, which the XPath formal semantics cannot guarantee.
  > 
  >     Functions that depend on anything beyond their parameters don't fit
  >     the design of XPath.
  > 
  >     This is a hard area. We're quite willing to work with you on
  >     designing this. (: We note that this function is new in XForms 1.1
  >     so there are no compatibility requirements here :)
  > 
  > 
  > 

15.34 Section 7

PROBLEM ID: 116

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

NOTES:

  These were all deemed editorial.  However, 22 is not so it has been moved to a
  separate issue.

ORIGINAL MESSAGE:

  From: "Aaron Reed" <aaronr@us.ibm.com>
  
  22) Section 7.2 - Shouldn't hasFeature return 1.1?  Otherwise how do I know
  if the processor handles 1.1 stuff?
  23) Section 7.4 - Double periods terminating the second sentence in the
  first paragraph.  Space before the period terminating the third sentence in
  the first paragraph.
  24) Section 7.8.5 - "The general method described in Resolving ID
  References in XForms is used to determine the desired run-time case
  object".  I assume you mean repeat object?
  25) Section 7.11.4 - "The node-set parameter provides nodes in one or more
  documents to be searched."  Can you give an example of how to specify a
  nodeset that applies to more than one document?
  

REPLY 1:

  From: John Boyer <xforms-issues@mn.aptest.com>
  
  Hi Aaron,
  
  Here are some responses to issues you raised in a last call email on April 30. 
  Spec changes are available in the editor's copy of the spec available from the
  Forms WG website.  Please let us know if you have any further concerns about
  these issues.
  
  Thanks,
  John Boyer
  
  23) Section 7.4 - Double periods terminating the second sentence in the
  first paragraph.  Space before the period terminating the third sentence in
  the first paragraph.
  
  Done. Not diff-marked.
  
  24) Section 7.8.5 - "The general method described in Resolving ID
  References in XForms is used to determine the desired run-time case
  object".  I assume you mean repeat object?
  
  Yes.  Fixed.  Not diff-marked.
  
  25) Section 7.11.4 - "The node-set parameter provides nodes in one or more
  documents to be searched."  Can you give an example of how to specify a
  nodeset that applies to more than one document?
  
  The document is an instance data document.  Fixed. Diff-marked.