XForms Working Group

XForms 1.0 Candidate Recommendation Disposition of Comments

Abstract

This document outlines the way in which the XForms Working Group addressed the comments submitted during the XForms 1.0 Candidate Recommendation period. This document has been created by the XForms Working Group.

Status of this document

During the Candidate Recommendation period for XForms 1.0, a number of comments were received from both inside and outside of the W3C. 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 Working Group elected to not change these submissions.

Status of resolution of comment:

1. 38 comments Accepted (accepted by the WG without change)
   [8 - 9 - 11 - 12 - 14 - 16 - 18 - 21 - 22 - 23 - 24 - 27 - 32 - 33 - 35 - 38 - 39 - 40 - 41 - 42 - 43 - 44 - 45 - 46 - 47 - 48 - 50 - 51 - 52 - 53 - 54 - 58 - 61 - 62 - 63 - 64 - 65 - 66]
2. 18 comments Resolved-OK (accepted with change by the WG, OK with the submitter)
   [4 - 10 - 15 - 17 - 19 - 20 - 25 - 26 - 28 - 29 - 30 - 31 - 37 - 49 - 55 - 56 - 57 - 60]
3. 01 comment Rejected (not accepted, OK with the submitter)
   [59 ]

Summary

1. ReadyForSignOff

1.1 XPath 2

PROBLEM ID: 56

NOTES:

  Micah Dubinko [mdubinko@Cardiff.com]
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0503.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Micah Dubinko [mailto:MDubinko@cardiff.com]
  Sent: Monday, December 16, 2002 4:46 PM
  To: 'Roland Merrick'
  Cc: w3c-forms@w3.org
  Subject: RE: XPath 2
  
  
  
  OK, Let's compare.
  
  yearMonth XPath:
  [\-]?P[0-9]+(Y([0-9]+M)?|M)
  yearMonth XForms:
  [-]?P\p{Nd}+(Y(\p{Nd}+M)?|M)
  
  Where XForms uses a Unicode escape \p{Nd}, XPath uses a specific character
  range. It would be in violation of the ISO-8601 specs to use any Unicode
  numeric character outside [0-9], so it defeats the purpose of having a
  pattern only to allow invalid characters.
  I note too that the XForms version incorrectly uses '-' without escaping.
  I suggest that XForms changes to use the XPath pattern.
  
  
  dayTime XPath:
  [\-]?P([0-9]+D(T([0-9]+(H([0-9]+(M([0-9]+(\.[0-9]*)?S
                        |\.[0-9]+S)?|(\.[0-9]*)?S)|(\.[0-9]*)?S)?|M([0-9]+
                        (\.[0-9]*)?S|\.[0-9]+S)?|(\.[0-9]*)?S)|\.[0-9]+S))?
                        |T([0-9]+(H([0-9]+(M([0-9]+(\.[0-9]*)?S|\.[0-9]+S)?
   
  |(\.[0-9]*)?S)|(\.[0-9]*)?S)?|M([0-9]+(\.[0-9]*)?S|\.[0-9]+S)?
                        |(\.[0-9]*)?S)|\.[0-9]+S))
  dayTime XForms:
  [-]?P((\p{Nd}D(T\p{Nd}+(H(\p{Nd}+M(\p{Nd}+([.]\p{Nd}+)?S)?)?|M(\p{Nd}+([.]\p
  {Nd}+)?S)?|(([.]\p{Nd}+)?S)))?)|T\p{Nd}+(H(\p{Nd}+M(\p{Nd}+([.]\p{Nd}+)?S)?)
  ?|M(\p{Nd}+([.]\p{Nd}+)?S)?|(([.]\p{Nd}+)?S)))
  
  Besides the Unicode and unescaped '-' issues, here the XPath pattern seems
  to use a slightly different overall structure.
  I suggest that XForms changes to use the XPath pattern.
  
  Thanks,
  
  .micah
  
  
  
  -----Original Message-----
  From: Roland Merrick [mailto:roland_merrick@uk.ibm.com]
  Sent: Monday, December 16, 2002 7:50 AM
  To: MDubinko@cardiff.com
  Cc: w3c-forms@w3.org
  Subject: XPath 2
  
  
  
  Greetings Micah, I've started reviewing the latest XPath 2.0 F&O spec and
  have got as far as their definitions of fn:yearMonthDuration &
  fn:dayTimeDuration. Their definitions do not use the same regular
  expressions as ours. Since you did the schema definition for our versions
  could you take a look to see if they are semantically equivalent even if
  syntactically different?
  
  Regards, Roland
  Ease of Use Strategy
  Tel: +44 (0)1926-465440,   Fax: +44 (0)1926-465323
  Internet: Roland_Merrick@uk.ibm.com
  Ease of Use:     http://www.ibm.com/easy/           http://w3.ibm.com/easy/

1.2 group and relevance vs. switch/case

PROBLEM ID: 57

NOTES:

  Leigh L Klotz, Jr.  
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0509.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Leigh L Klotz, Jr. [mailto:Leigh.Klotz@pahv.xerox.com]
  Sent: Tuesday, December 17, 2002 9:11 AM
  To: w3c-forms@w3c.org
  Subject: group and relevance vs. switch/case
  
  
  
  One of the arguments made about groups whose ref points to a node that 
  has model item property relevant=false  is that it is analogous to an 
  input control with an output inside the label, neither of which which 
  should be displayed if the input is not relevant.  This parallel brings 
  up a couple of related issues:
  
  1. Does this input/label/output non-display apply to other content of 
  label? Are non-xforms elements displayed inside labels of inputs bound 
  to relevant=false nodes? I assume they do not display either.
  2. If that is the case, should group be the same? That is, should 
  non-xforms elements inside group not be displayed if the group is bound 
  via ref to a node whose relevant=false?
  3. Voila, we have a model-based version of switch and case! (Well, a a 
  boolean version, but close enough.)

1.3 Revalidation of nodes in the relevant subtree being submitted

PROBLEM ID: 55

NOTES:

  John Boyer [JBoyer@PureEdge.com]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Dec/0006.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: John Boyer [mailto:JBoyer@PureEdge.com]
  Sent: Wednesday, December 11, 2002 2:33 PM
  To: www-forms-editor@w3.org
  Subject: Revalidation of nodes in the relevant subtree being submitted
  
  
  
  
  The working group seems to uniformly agree that only the relevant nodes in
  the instance tree or subtree being submitted are to be revalidated.
  
  However, Section 11.1 says that 'All selected instance data' is to be
  revalidated **according to the rules in Section 4.3.5**, which says to
  validate the whole instance (actually it says to validate all instances).
  One could reasonably conclude that the whole instance containing the
  selected instance data is to be revalidated.  
  
  A clarification to Section 11.1 would help.  Here is a suggestion for the
  new wording:
  
  2. Within the selected instance or subtree indicated by the <submission> ref
  attribute, all relevant nodes are revalidated using the rules that '4.3.5
  The xforms-revalidate Event' normally applies to all nodes. Any invalid
  instance data stops submit processing after dispatching event
  xforms-submit-error.
  
  Separately, there still seems to be some question about whether structural
  validation is done or whether only datatype validation is done.  To me, the
  spec clearly indicates that all nodes (that are relevant and in the subtree
  being submitted) will be revalidated, whether that means structural or
  datatype revalidation.  If an alternate meaning is intended, then it needs
  to be clarified.
  
  Thanks,
  John Boyer, Ph.D.
  Senior Product Architect
  PureEdge Solutions Inc.
   

1.4 Minor spec wording change request

PROBLEM ID: 8

NOTES:

  ?? Rob.McDougall@adobe.com
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0201.html
  
  11 Feb 2003: 2nd paragraph (adding "subsequent") is the desired change (MUST)
  Add wording (see minutes) to disable the  control (MUST)

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  This message is in MIME format. Since your mail reader does not understand
  this format, some or all of this message may not be legible.
  
  ------_=_NextPart_001_01C295A7.1A2F26D0
  Content-Type: text/plain;
          charset="iso-8859-1"
  
   
  -----Original Message-----
  From: Klotz, Leigh [mailto:Leigh.Klotz@pahv.xerox.com]
  Sent: Thursday, October 31, 2002 5:19 PM
  To: 'Rob McDougall'; 'w3c-forms@w3.org'
  Subject: RE: Minor spec wording change request
  
  
   
  
  -----Original Message-----
  From: Rob McDougall [mailto:Rob.McDougall@adobe.com] 
  Sent: Thursday, October 31, 2002 4:21 PM
  To: 'w3c-forms@w3.org'
  Subject: Minor spec wording change request
  
  
  
  Hi,
  
   
  
  While Roland and I were reviewing the 11. Submission section we ran across
  the following sentence:
  
   
  
  "Under no circumstances may more than a single concurrent submit process be
  under way for a particular XForms Model. From the start of the default
  processing of xforms-submit, until the completion of default processing for
  xforms-submit-done or xforms-submit-error, the default processing for event
  xforms-submit is to terminate immediately."
  
   
  
  We found this confusing because in the last segment the xforms-submit event
  referred to is a different event that in the first segment of the sentence.
  It would be nice if this was re-worded to
  
   
  
  "Under no circumstances may more than a single concurrent submit process be
  under way for a particular XForms Model. From the start of the default
  processing of xforms-submit, until the completion of default processing for
  xforms-submit-done or xforms-submit-error, the default processing for any
  subsequent xforms-submit events is to be ignored."
  
   
  
  One more thing.  The sentence says "the default processing".  Does that mean
  that if one specifies non-default processing, then you can have multiple
  xforms-submit events at the same time?  If not, then I would change the
  sentence to read
  
   
  
  "Under no circumstances may more than a single concurrent submit process be
  under way for a particular XForms Model. From the start of the default
  processing of xforms-submit, until the completion of default processing for
  xforms-submit-done or xforms-submit-error, any subsequent xforms-submit
  events are ignored." 
  
   
  
  Surely the XML events machinery doesn't ignore them -- it's the handler that
  does the ignoring, and we have to say that.  In other words, I don't see how
  we can legislate what author-specified processing for the xforms-submit
  event is; we can only say what our handler for the event does.  If someone
  has a handler for xforms-submit that does something else, then we can't keep
  teh submit button from sending the event to and we can't keep that handler
  from being run.  What we can do is keep the handler that defined into
  existence by default on the submission element from doing anything.  This
  all seems reasonable to me.  The last proposed rewording above doesn't say
  who ignores the events.   
  
   
  
  Regards,
  
  Rob
  
  ________________________________________ 
  
  Rob McDougall
  Sr. Computer Scientist
  
  Adobe Systems Incorporated
  Phone: +1 613.940.3708
  Fax: +1 613.594.8886
  E-mail:  <mailto:rob.mcdougall@adobe.com> rob.mcdougall@adobe.com
  
   
  
  
  ------_=_NextPart_001_01C295A7.1A2F26D0
  Content-Type: text/html;
          charset="iso-8859-1"
  
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  <HTML><HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
  <TITLE>Message</TITLE>
  
  <META content="MSHTML 6.00.2800.1126" name=GENERATOR>
  <STYLE>@font-face {
          font-family: Garamond;
  }
  @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
  P.MsoNormal {
          FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
  }
  LI.MsoNormal {
          FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
  }
  DIV.MsoNormal {
          FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
  }
  A:link {
          COLOR: blue; TEXT-DECORATION: underline
  }
  SPAN.MsoHyperlink {
          COLOR: blue; TEXT-DECORATION: underline
  }
  A:visited {
          COLOR: purple; TEXT-DECORATION: underline
  }
  SPAN.MsoHyperlinkFollowed {
          COLOR: purple; TEXT-DECORATION: underline
  }
  CODE {
          FONT-FAMILY: "Courier New"
  }
  SPAN.EmailStyle17 {
          COLOR: windowtext; FONT-FAMILY: Arial
  }
  DIV.Section1 {
          page: Section1
  }
  </STYLE>
  </HEAD>
  <BODY lang=EN-US vLink=purple link=blue>
  <DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Klotz, Leigh 
  [mailto:Leigh.Klotz@pahv.xerox.com]<BR><B>Sent:</B> Thursday, October 31, 2002 
  5:19 PM<BR><B>To:</B> 'Rob McDougall'; 'w3c-forms@w3.org'<BR><B>Subject:</B> RE: 
  Minor spec wording change request<BR><BR></FONT></DIV>
  <DIV><SPAN class=757231501-01112002><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
    face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Rob McDougall 
    [mailto:Rob.McDougall@adobe.com] <BR><B>Sent:</B> Thursday, October 31, 2002 
    4:21 PM<BR><B>To:</B> 'w3c-forms@w3.org'<BR><B>Subject:</B> Minor spec wording 
    change request<BR><BR></FONT></DIV>
    <DIV class=Section1>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi,</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">While Roland and I were reviewing 
    the 11. Submission section we ran across the following 
    sentence:</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT><FONT face=Arial 
    color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial">Under no 
    circumstances may more than a single concurrent submit process be under way 
    for a particular XForms Model. From the start of the default processing of 
    </SPAN></FONT><CODE><FONT face="Courier New" color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial">, until 
    the completion of default processing for </SPAN></FONT><CODE><FONT 
    face="Courier New" color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit-done</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial"> or 
    </SPAN></FONT><CODE><FONT face="Courier New" color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit-error</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial">, the 
    default processing for event </SPAN></FONT><CODE><FONT face="Courier New" 
    color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial"> is to 
    terminate immediately.</SPAN></FONT><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">We found this confusing because in 
    the last segment the </SPAN></FONT><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">xforms-submit</SPAN></FONT><FONT 
    face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> event 
    referred to is a different event that in the first segment of the 
    sentence.&nbsp; It would be nice if this was re-worded to</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT><FONT face=Arial 
    color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial">Under no 
    circumstances may more than a single concurrent submit process be under way 
    for a particular XForms Model. From the start of the default processing of 
    </SPAN></FONT><CODE><FONT face="Courier New" color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial">, until 
    the completion of default processing for </SPAN></FONT><CODE><FONT 
    face="Courier New" color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit-done</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial"> or 
    </SPAN></FONT><CODE><FONT face="Courier New" color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit-error</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial">, the 
    default processing for any subsequent </SPAN></FONT><CODE><FONT 
    face="Courier New" color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial"> events 
    is to be ignored.</SPAN></FONT><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">One more thing.&nbsp; The sentence 
    says "the default processing".&nbsp; Does that mean that if one specifies 
    non-default processing, then you can have multiple </SPAN></FONT><FONT 
    face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">xforms-submit</SPAN></FONT><FONT 
    face=Arial size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> events at 
    the same time?&nbsp; If not, then I would change the sentence to 
    read</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">"</SPAN></FONT><FONT face=Arial 
    color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial">Under no 
    circumstances may more than a single concurrent submit process be under way 
    for a particular XForms Model. From the start of the default processing of 
    </SPAN></FONT><CODE><FONT face="Courier New" color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial">, until 
    the completion of default processing for </SPAN></FONT><CODE><FONT 
    face="Courier New" color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit-done</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial"> or 
    </SPAN></FONT><CODE><FONT face="Courier New" color=black size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit-error</SPAN></FONT></CODE><FONT 
    face=Arial color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial">, any 
    subsequent </SPAN></FONT><CODE><FONT face="Courier New" color=black 
    size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: black">xforms-submit</SPAN></FONT></CODE><FONT 
    color=black><SPAN style="COLOR: black; FONT-FAMILY: Arial"> events are 
    ignored.</SPAN></FONT><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">"<SPAN 
    class=757231501-01112002><FONT color=#0000ff>&nbsp;</FONT></SPAN></SPAN></P>
    <P class=MsoNormal><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN 
    class=757231501-01112002></SPAN></SPAN>&nbsp;</P></DIV></BLOCKQUOTE>
  <P class=MsoNormal dir=ltr><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN class=757231501-01112002><SPAN 
  class=757231501-01112002><FONT face=Arial color=#0000ff size=2>Surely 
  the&nbsp;XML events machinery doesn't ignore them -- it's the handler 
  that&nbsp;does the ignoring, and we have to say that.&nbsp; In other words, I 
  don't see how we can legislate what author-specified processing for the 
  xforms-submit event is; we can only say what our handler for the event 
  does.&nbsp; If someone</FONT></SPAN>&nbsp;<FONT color=#0000ff>has a handler for 
  xforms-submit that does something else, then we can't keep teh submit button 
  from sending the event to and we can't keep that handler from being run.&nbsp; 
  What we can do is keep the handler that defined into existence by default on the 
  submission element from doing anything.&nbsp; This all seems reasonable to 
  me.&nbsp;&nbsp;The last proposed&nbsp;rewording above doesn't say who ignores 
  the events.&nbsp;&nbsp;&nbsp;</FONT></SPAN></SPAN></P>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Regards,</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Rob</SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=red size=2><SPAN 
    style="FONT-SIZE: 11pt; COLOR: red; FONT-FAMILY: Arial">________________________________________</SPAN></FONT> 
    </P>
    <P class=MsoNormal><B><FONT face=Garamond size=2><SPAN 
    style="FONT-WEIGHT: bold; FONT-SIZE: 11pt; FONT-FAMILY: Garamond">Rob 
    McDougall</SPAN></FONT></B><B><FONT face=Garamond size=2><SPAN 
    style="FONT-WEIGHT: bold; FONT-SIZE: 11pt; FONT-FAMILY: Garamond"><BR></SPAN></FONT></B><I><FONT 
    face=Garamond size=2><SPAN 
    style="FONT-SIZE: 11pt; FONT-STYLE: italic; FONT-FAMILY: Garamond">Sr. 
    Computer Scientist</SPAN></FONT></I></P>
    <P class=MsoNormal><B><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-WEIGHT: bold; FONT-SIZE: 12pt">Adobe&nbsp;Systems 
    Incorporated</SPAN></FONT></B><FONT color=gray><SPAN 
    style="COLOR: gray"><BR></SPAN></FONT>Phone:&nbsp;+1 613.940.3708<BR>Fax: +1 
    613.594.8886<BR>E-mail: <A href="mailto:rob.mcdougall@adobe.com"><FONT 
    face=Garamond size=2><SPAN 
    style="FONT-SIZE: 11pt; FONT-FAMILY: Garamond">rob.mcdougall@adobe.com</SPAN></FONT></A></P>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></BLOCKQUOTE></BODY></HTML>
  
  ------_=_NextPart_001_01C295A7.1A2F26D0--

1.5 re: 6.2.1 document order of type declaration

PROBLEM ID: 9

NOTES:

  F2F resolution 3/3/3 - Apply all items in numeric order / inconsistencies
  result
  in nodes that are always invalid. SPEC CHANGE to 6.2.1.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: John Keiser [mailto:jkeiser@netscape.com]
  Sent: Friday, November 01, 2002 4:32 PM
  To: w3c-forms@w3.org
  Subject: re: 6.2.1 document order of type declaration
  
  
  
  Leigh and I were looking at the "document order" section of 6.2.1, which
  defines where and how we associate datatypes with nodes.  The definition
  of document order seems counterintuitive.  Furthermore, it allows an
  instance or a bind to specify a type that will be invalid.  XML Schema
  resolves conflicts between different types applying to the same element
  by saying if they are inconsistent, the document is invalid:
  http://www.zvon.org/xxl/XMLSchemaTutorial/Output/ser_over_st1.html.  We
  are proposing a modification as follows:
  
  The set of facets may be associated with a model item in one of the
  following ways.  The most specific type declaration applies.  If any of 
  the supplied types are inconsistent, then a terminating error occurs.
  
      . An XML Schema associated with the namespace.
      . An XML Schema xsi:type attribute in the instance data.
      . An XForms <att>type</att> constraint associated with the instance 
  data node using XForms <el>bind</el>
  
  If no type constraint is provided, the instance data node defaults to 
  type="xsd:string" (default to string rule).
  
  --John
  

1.6 CR ISSUE: Binding Expressions

PROBLEM ID: 12

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Micah Dubinko [mailto:MDubinko@cardiff.com]
  Sent: Thursday, November 07, 2002 11:59 AM
  To: 'John Boyer'; 'w3c-forms@w3.org'
  Subject: RE: CR ISSUE: Binding Expressions
  
  
  
  Agree. Instead of "LocationPath" (production [1] in XPath), we should refer
  to "PathExpr" (production [19]).
  
  A search-and-replace ought to do it.
  
  Thanks!
  
  .micah
  
  -----Original Message-----
  From: John Boyer [mailto:JBoyer@PureEdge.com]
  Sent: Thursday, November 07, 2002 9:56 AM
  To: w3c-forms@w3.org
  Subject: CR ISSUE: Binding Expressions
  
  
  
  Section 7.4
  
  THE SPEC INCORRECTLY RESTRICTS TO LOCATIONPATH, BUT MULTIPLE INSTANCES DO
  NOT WORK IF THIS IS THE CASE. 
  
  John Boyer, Ph.D.
  Senior Product Architect
  PureEdge Solutions Inc.
   

1.7 CR Issue: DOMFocusXXX should bubble

PROBLEM ID: 35

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Mikko Honkala [mailto:honkkis@tml.hut.fi]
  Sent: Tuesday, November 19, 2002 6:30 AM
  To: www-forms-editor@w3.org
  Subject: CR Issue: DOMFocusXXX should bubble 
  
  
  
  
  There's a bug in the CR Draft.
  
  DOMFocusIn & DOMFocusOut should have 'Bubbles: Yes' (and not 'No' as it
  does in the XForms CR draft)
  
  as in DOM2 Events:
  http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events
  -UIEvent
  
  and DOM3 Events
  http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/events.html
  
  -mikko
  
  

1.8 The child of <instance>

PROBLEM ID: 37

NOTES:

  F2F 3/3/3 change to "arbitrary XML that would be well-formed if it existed in a
  separate document. Note that this restricts the XML to a single root element."
  
  Answers: right, wrong.
  
  3/17 MJD - this has already been partially fixed by the new wording around
  includenamespaceprefixes. Just adding the bit about a single element root.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Alex Rosen [mailto:arosen@novell.com]
  Sent: Friday, November 22, 2002 8:21 AM
  To: www-forms@w3.org
  Subject: The child of <instance>
  
  
  
  Section 3.3.2 says "The content of the instance element is arbitrary XML in
  any namespace." This is not quite true, since it can have at most one child
  element (tree). (In general, this single-child requirement is somewhat
  burried in the spec - it would be nice to make it explicit in this section.)
  
  Only form controls, the <model>, and the <submission> can contain action
  elements, which make it easier to define event handlers for them. That means
  that to create handlers for <item>, <case>, and <instance>, you have to put
  the handler somewhere else, right? (Other than directly underneath the
  target element.)
  
  Actually, since <instance> can contain any XML element, it could contain an
  action element too. I can imagine someone using an src link to external
  instance data, and adding an action element as an event handler for the
  instance node. The spec should probably say whether this is allowed or
  disallowed.
  
  Alex
  

1.9 RE: Nested repeats and index

PROBLEM ID: 38

NOTES:

  Kenneth Sklander [mailto:ksklander@novell.com]
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0079.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Kenneth Sklander [mailto:ksklander@novell.com]
  Sent: Thursday, October 10, 2002 12:47 AM
  To: Micah Dubinko; w3c-forms@w3c.org
  Subject: Re: Nested repeats and index
  
  
  Hi,
  
  We suggest that the following text substitutes existing text for bullet 3,
  in 9.3.6 - The Delete Element:
  ----
  3. The index should point to the same node after a delete as it did before
  the delete except when:
      - the last remaining item in the collection is removed, the index
  position becomes 0.
      - the index was pointing to the deleted node, the index position is
  processed using these rules:
          - If the index was pointing to the last node in the collection, the
  index will point to the
          new last node of the collection and the index of inner repeats is
  reinitialized.
          - If the index was pointing to any node but the last in the
  collection. the index position is         not changed and the index of inner
  repeats is re-initialized.
  
  
  Note. re-initialized means that the index becomes 1 if the collection is
  non-empty otherwise 0.
  -----
  (btw: we note is valid for all re-initializations of indexes used in insert
  and setindex)
  
  
  Kenneth and David
  
  ----- Original Message -----
  From: "Micah Dubinko" <MDubinko@cardiff.com>
  To: "'David Landwehr'" <dlandwehr@novell.com>; "w3c-forms"
  <w3c-forms@w3c.org>
  Sent: Tuesday, October 01, 2002 8:23 PM
  Subject: RE: Nested repeats and index
  
  
  >
  > Hi Guys,
  >
  > I agree with your findings, but I'm having trouble pinning down an exact
  > spec change.
  >
  > Can you pinpoint where the text needs to be added/changed and provide a
  > concrete suggestion?
  >
  > Thanks!
  >
  > .micah
  >
  > -----Original Message-----
  > From: David Landwehr [mailto:dlandwehr@novell.com]
  > Sent: Tuesday, October 01, 2002 5:21 AM
  > To: w3c-forms
  > Subject: Nested repeats and index
  >
  >
  >
  > We have investigated the nested repeats and the index behavior. We found
  > two issues both in relevance to delete:
  > 1. Indexes pointing to inner repeats might point to invalid nodes after
  > a delete:
  >   Ex:
  >      a         <- index for outer repeat
  >           b
  >           b
  >           b    <- index for inner repeat
  >      a
  >           b
  >
  > delete the node pointed to by the outer repeat. The indexes is still 1
  > and 3, with no 3rd node in the inner repeat.
  >
  > 2. The index might jump after a delete.
  > Ex:
  >    a[1]
  >    a[2]
  >    a[3]
  >    a[4]    <- index for repeat
  >    a[5]
  >
  > deleting the node (a[1]) moves the index to point to the first node
  > according to the spec. 9.3.6 bullet 3
  >
  >    a[2]   <- index for repeat
  >    a[3]
  >    a[4]
  >    a[5]
  >
  > We think this is counterintuitive.
  >
  > We suggest that the index points to the same node (not index) after a
  > delete. If the node delete is the one pointed to by the index, the index
  > value is not changed (and the inner repeat indexes is reset to 1 as for
  > setindex). Only if  index points to the last node in the collection and
  > that is the node to be deleted, then the index is moved to index=last()
  > (and inner repeats is reset to 1).
  >
  > Kenneth and David
  >
  >

1.10 CR ISSUE: section 4.2.1 bullet 1

PROBLEM ID: 39

NOTES:

  F2F 3/3/3 change to "access or process"

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: David Landwehr [mailto:DLandwehr@novell.com]
  Sent: Wednesday, November 27, 2002 4:39 AM
  To: w3c-forms@w3.org
  Subject: CR ISSUE: section 4.2.1 bullet 1
  
  
  
  Should specify that xforms-link-exception is dispatched when loading
  something which is not a schema.

1.11 CR ISSUE: section 4.2.1 bullet 2

PROBLEM ID: 40

NOTES:

  F2F 3/3/3 Accepted. SPEC CHANGE 4.2.1 #2

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: David Landwehr [mailto:DLandwehr@novell.com]
  Sent: Wednesday, November 27, 2002 4:42 AM
  To: w3c-forms@w3.org
  Subject: CR ISSUE: section 4.2.1 bullet 2
  
  
  
  Should dispatch an xforms-link-exception if external instance could not be
  retrieved or is not well-formed XML.

1.12 CR ISSUE: section 4.2.6 - model-destruct

PROBLEM ID: 42

NOTES:

  F2F 3/3/3 Agreed. Accepted.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Kenneth Sklander [mailto:ksklander@novell.com]
  Sent: Wednesday, November 27, 2002 5:27 AM
  To: w3c-forms@w3c.org
  Subject: CR ISSUE: section 4.2.6 - model-destruct
  
  
  
  xforms-model-destruct should be dispatched when a model is destructed, which
  beyond shutting down the processor could happen by the load action or after
  a submit with replace="all".

1.13 CR ISSUE: Minor clarification for instance tree/subtree

PROBLEM ID: 43

NOTES:

  F2F 3/3/3 Accepted. SPEC CHANGE

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: John Boyer [mailto:JBoyer@PureEdge.com]
  Sent: Thursday, November 28, 2002 9:33 AM
  To: www-forms-editor@w3.org
  Subject: CR ISSUE: Minor clarification for instance tree/subtree
  submission
  
  
  
  
  Section 11.1 defines steps for default processing of the xforms-submit
  event.
  
  The first step says "A node from the instance data is selected, based on the
  attribute ref on element submission. This node and all relevant child nodes
  are considered for the remainder of the submit process."
  
  The second sentence needs to be change to "This node and all nodes for which
  it is an ancestor are considered for the remainder of the submit process."
  
  This more clearly communicates that we want the entire subtree rooted by the
  referenced node, including attributes and namespaces.
  
  Due to a technical 'hiccup' in the XPath data model, attributes and
  namespaces have their containing element as a parent, but the parent does
  not have the attributes and namespaces as children.  
  
  John Boyer, Ph.D.
  Senior Product Architect
  PureEdge Solutions Inc.

1.14 CR ISSUE: Clarification of default for ref attribute of

PROBLEM ID: 44

NOTES:

  F2F 3/3/3 default for  is "/"

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: John Boyer [mailto:JBoyer@PureEdge.com]
  Sent: Thursday, November 28, 2002 10:01 AM
  To: www-forms-editor@w3.org
  Subject: CR ISSUE: Clarification of default for ref attribute of
  submission element
  
  
  
  
  Section 3.3.1 does not indicate the default for the ref attribute of the
  submisssion element.  Two issues exist:
  
  1) We must define whether by default the 'ref' references the root node or
  the root element node (a.k.a. the document element) of the instance data.
  
  By submitting only the root element, comment and processing instructions
  outside of the instance's root element are not serialized (whether the
  initial instance was given inline or by a link).
  
  My current assumption is that it is the root element, not the root node,
  because this is consistent with the return type of the instance() function.
  It should not be possible to submit those external comments and PIs for
  single instance forms if they cannot also be submitted for multiple
  instances where the instance is specified.
  
  The alternative seems to be to have instance() return the root node, not the
  root element.
  
  2) We must define whether the first instance in build order is used by
  default in multiple instance documents, or whether ref is mandatory in
  multiple instance documents.
  
  My assumption is that if there are multiple instances, and a <submission>
  contains no ref attribute, then the first xforms:instance in build order is
  the one to be submitted.  This is consistent with what happens if there is
  only one instance, and it maintains the notion that ref is an optional
  attribute, which is what is stated in Section 3.3.1.
  
  Thanks,
  John Boyer, Ph.D.
  Senior Product Architect
  PureEdge Solutions Inc.

1.15 11.1 Minor omission

PROBLEM ID: 45

NOTES:

  F2F - Accepted.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Micah Dubinko [mailto:mdubinko@yahoo.com]
  Sent: Friday, November 29, 2002 11:49 AM
  To: www-forms-editor@w3.org
  Subject: 11.1 Minor omission
  
  
  
  
  This section says, in bullet #1:
  
  "A node from the instance data is selected, based on the attribute ref
  on element submission."
  
  Based on the description of <submission> in the Schema and in section
  3.3.3, for consistency this sentence should also state that the 'bind'
  attribute can also be used to select a node, and that if both 'bind'
  and 'ref' are present, 'bind' takes precedence (just as with binding
  attributes).
  
  Section 3.3.3 seems to have some minor editorial cosmetic problems,
  including a spurious "XML Representation: <submission>".
  
  Thank you,
  
  .micah
  
  =====
  Find out what the fuss about XForms is all about. Full text of my book
  in-progress online at http://dubinko.info/writing/xforms/
  
  __________________________________________________
  Do you Yahoo!?
  Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
  http://mailplus.yahoo.com

1.16 11.5 urlencoding -- tiny clarifications needed

PROBLEM ID: 46

NOTES:

  F2F no change on first, use %NN (upper), answer: yes '%' needs escaping (but no
  spec change)

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Micah Dubinko [mailto:mdubinko@yahoo.com]
  Sent: Friday, November 29, 2002 9:36 PM
  To: www-forms-editor@w3.org
  Subject: 11.5 urlencoding -- tiny clarifications needed
  
  
  
  
  Bullet #1 says:
  "Each element that has one text node child is selected for inclusion."
  
  This sentence really ought to say "one (and only one) text child node".
  
  
  The sub-bullet under #2 says:
  
  "each octet in turn replaced by %HH, where HH represents the
  hexadecimal notation for the octet value"
  
  This sentence really ought to mandate either upper-case or lower-case
  letters for the hex value. (Is it %AB or %ab ?) The following example
  uses upper-case, as does HTML 4.01.
  
  Finally, a question. According to the algorithm in this section, do '%'
  characters in form data need to be escaped or not?
  
  Thank you,
  
  .micah
  
  =====
  Find out what the fuss about XForms is all about. Full text of my book
  in-progress online at http://dubinko.info/writing/xforms/
  
  __________________________________________________
  Do you Yahoo!?
  Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
  http://mailplus.yahoo.com

1.17 evaluation context contradiction

PROBLEM ID: 47

NOTES:

  F2F -- already changed

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Paul Butcher [mailto:Paul.Butcher@x-port.net]
  Sent: Tuesday, December 03, 2002 8:01 AM
  To: 'www-forms@w3.org'
  Subject: evaluation context contradiction
  
  
  
  There seems to be a contradiction in the current XForms spec regarding the
  evaluation context for XPath expressions in model item properties.  Consider
  the following two excerpts:
  
  (a) http://www.w3.org/TR/2002/CR-xforms-20021112/slice4.html#evt-recalculate
  
  states:
  When it is time to recalculate a compute, the XPath expression is evaluated
  in the context of the instance node whose value or model item property is
  associated with the compute.
  
  (b) http://www.w3.org/TR/2002/CR-xforms-20021112/slice7.html#expr-eval
  Point 4 states:
   The context node for computed expressions (occurring on element bind) is
  the first node of the node-set returned from the binding expression in the
  nodeset attribute on the same element.
  
  Both of the rules define different context nodes for the evaluation of XPath
  in model item property attributes.
  
  The problem:
  
  Given the following model definition:
  <xf:model id="m1">
          <xf:instance>
                  <x>
                          <y>a very, very long string indeed</y>
                          <y>short string</y>
                  </x>
          </xf:instance>
          <xf:bind nodeset="y" constraint="string-length(.) &lt; 15" /> 
  </xf:model>
  
  And the following two elements:
  
  <xf:output model="m1" ref="y[1]" id="o1" />
  <xf:output model="m1" ref="y[2]" id="o2" />
  
  If the rule at (a) above is applied, both outputs would be marked as invalid
  at the start, until the content of the first <y> element is sufficiently
  shortened.
  
  If the rule at (b) above is applied, then output "o1" would be marked as
  invalid, and the output "o2" valid.
  
  If they are both correct, then both outputs would be marked as invalid until
  a recalculate is forced, at which point the output "o2" would become valid.
  However, since "xforms-recalculate" occurs during "xforms-model-initialize"
  processing, the rule at (b) is redundant, because there is no situation in
  which a computed expression is evaluated outside the processing of
  "xforms-recalculate"
  
  For the next version of Formsplayer, we have assumed that (a) is the correct
  behaviour, that the context node for model item properties is the node with
  which the property is associated.
  
  
  Paul Butcher
  FormsPlayer Lead Programmer
  x-port.net Ltd.
  4 Pear Tree Court
  London
  EC1R 0DS
  
  Try our XForms plug-in for IE
  at http://www.FormsPlayer.com/

1.18 CR Issue 4.3.2 Focus

PROBLEM ID: 50

NOTES:

  F2F 4 Feb 2003 - add "if the form control is able to accept focus". Accepted.

ORIGINAL MESSAGE:

  From: ksklander@novell.com
  
  Full_Name: Kenneth Sklander
  Submission from: (NULL) (195.215.69.206)
  
  
  When setting focus to a control that is disabled or otherwise incapable of
  holding focus, we should specify what will happen.
  
  perhaps that the focus is unchanged ?
  
  
  /Kenneth

1.19 CR Issue: 4.3.8 Reset

PROBLEM ID: 51

NOTES:

  F2F 4 Feb 2003 Accepted. New event name is 'xforms-ready'. Reset brings the
  form
  back to the state it was in for that event.

ORIGINAL MESSAGE:

  From: ksklander@novell.com
  
  Full_Name: Kenneth Sklander
  Submission from: (NULL) (195.215.69.206)
  
  
  when resetting a form that initially did not have an instance document, but an
  instance was created from the form control refs the form will no longer work,
  because the instance data is set to the state it had after processing
  xforms-initialize-done, but the default instance is create on
  xforms-form-control-initialize.
  
  Perhaps the reset should revert to the state it had after every
  xforms-form-control-initialze events had been fired?
  
  /kenneth

1.20 xforms-activate vs. DOMActivate

PROBLEM ID: 58

NOTES:

  Micah Dubinko [mdubinko@Cardiff.com]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Dec/0008.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Micah Dubinko [mailto:mdubinko@yahoo.com]
  Sent: Sunday, December 22, 2002 9:31 PM
  To: www-forms-editor@w3.org
  Subject: xforms-activate vs. DOMActivate
  
  
  
  
  I believe that the event xforms-activate is completely redundant with
  the already-defined (in DOM Level 2 Events) DOMActivate.
  
  Please change XForms to refer to DOMActivate instead of
  xforms-activate.
  
  Note: There is precedent for this, as the Candidate Recommendation
  document already refers to the related events DOMFocusIn and
  DOMFocusOut.
  
  Thanks,
  
  .micah
  
  =====
  Find out what the fuss about XForms is all about. Full text of my book
  in-progress online at http://dubinko.info/writing/xforms/
  
  __________________________________________________
  Do you Yahoo!?
  Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
  http://mailplus.yahoo.com

1.21 Editorial: required / optional binding

PROBLEM ID: 61

NOTES:

  Mikko Honkala [honkkis@tml.hut.fi]
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0532.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Mikko Honkala [mailto:honkkis@tml.hut.fi]
  Sent: Friday, December 27, 2002 3:47 AM
  To: w3c-forms@w3c.org
  Subject: Editorial: required / optional binding
  
  
  
  Hi,
  
  some elements that use single-node-binding require binding attribute to 
  exist, e.g. most form controls. In the other hand, for many elements the 
  binding is optional. (See list in the end).
  Still, in 3.2.3 Single-Node Binding Attributes, we say that "One of ref 
  or bind is required."
  
  This is impossible to express this in schema, since e.g. ref is always 
  optional (you can use bind instead), so it should be expressed in text 
  better. One way would be to mark all optional usages of 
  single-node-binding. For instance in "9.1.1 The group Element" we could 
  say:
  
  Common Attributes: Common, UI Common , (Optional)Single Node Binding
  
  
  At least the following elements use optional single-node-binding
  
  - output
  - label
  - group
  - message
  - switch
  - button
  - submit
  - hint
  - help
  - alert
  - value
  - copy
  - load
  
  
  
  -mikko

1.22 1.4 Document conventions

PROBLEM ID: 64

NOTES:

  "Steven Pemberton" 
  http://lists.w3.org/Archives/Public/www-forms-editor/2003Jan/0006.html
  
  F2F 4 Feb 2003 Accepted

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:Steven.Pemberton@cwi.nl]
  Sent: Tuesday, January 21, 2003 6:57 AM
  To: www-forms-editor@w3.org
  Subject: 1.4 Document conventions
  
  
  
  
  Please list the actual values for the namespace URIs needed, so that the
  reader doesn't have to search in other specifications to find them.
  
  Steven Pemberton
  
  

1.23 3.3.3 The submission Element

PROBLEM ID: 65

NOTES:

  "Steven Pemberton" 
  http://lists.w3.org/Archives/Public/www-forms-editor/2003Jan/0007.html
  
  F2F 4 Feb 2003 - Accepted.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:Steven.Pemberton@cwi.nl]
  Sent: Tuesday, January 21, 2003 6:58 AM
  To: www-forms-editor@w3.org
  Subject: 3.3.3 The submission Element
  
  
  
  
  Please include a link to chapter 11 Submit, to explain the meaning of
  attributes such as 'replace'.
  
  Steven Pemberton
  
  
  

1.24 AI: Action 2002-12-10.5 :setINDEX outside repeat range

PROBLEM ID: 66

NOTES:

  F2F 4 Feb 2003 - Accepted.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Mikko Honkala [mailto:honkkis@tml.hut.fi]
  Sent: Tuesday, February 04, 2003 9:13 AM
  To: w3c-forms@w3c.org
  Subject: AI: Action 2002-12-10.5 :setINDEX outside repeat range
  
  
  
  Hi I got the AI to clarify this issue, so here goes a try:
  
  ISSUE: We currently do not define what happens if somebody does
  setindex outside the range of the repeat. For instance, there is a 
  repeat that has 5 items (valid index values [1..5]). What happens for 
  <setindex index="-1"/> or <setindex index="666"/>?
  
  POSSIBLE SOLUTION:
  If index<1 then index=1 and dispatch xforms-scroll-first.
  If index>max then index=max and dispatch xforms-scroll-last.
  (This solution would mean a SPEC CHANGE to "9.3.7 The setindex Element").
  
  -mikko

1.25 CR ISSUE: Incorrect XPath Initial Context

PROBLEM ID: 11

NOTES:

  F2F 3/3/3 - Accepted

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Micah Dubinko [mailto:MDubinko@cardiff.com]
  Sent: Thursday, November 07, 2002 11:57 AM
  To: 'John Boyer'; w3c-forms@w3.org
  Subject: RE: CR ISSUE: Incorrect XPath Initial Context
  
  
  
  Hi John,
  
  Everyone agrees that "../units * ../price" should work, and implementations
  have been getting it to work. The trick is making the spec say the right
  things! :-)
  
  Section 7.3 is about the XPath context node, so you have to be careful about
  not saying "for each", which implies processing. A context node is a
  singular thing, separate from processing.
  
  What we need to say is that the context node on <bind> has, uh, late
  binding.
  
  Perhaps:
  
  "4. The context node for computed expressions (occurring on element bind) is
  the "current node", as defined by [XSLT], with the current node list being
  the node-set returned by the binding expression in the nodeset attribute on
  the same element."
  
  
  On bullet 5, can you show an example of an expression affected by this
  proposed change?
  
  Thanks!
  
  .micah
  
  -----Original Message-----
  From: John Boyer [mailto:JBoyer@PureEdge.com]
  Sent: Thursday, November 07, 2002 9:56 AM
  To: w3c-forms@w3.org
  Subject: CR ISSUE: Incorrect XPath Initial Context
  
  
  
  Section 7.3 Rule 4
  
  RULE IS INCORRECT; IT SHOULD SAY THAT for each node N in the nodeset
  identified by the bind element's nodeset attribute, a computed expression is
  evaluated with N as the context node.
  
  Section 7.3 Rule 5
  
  IT SHOULD SAY THAT THE POSITION IS PROPERLY SET, NOT THAT IT IS UNIFORMLY 1.
  
  
  Without these changes, relative expressions such as Subtotal=../units *
  ../price do not work.
  
  John Boyer, Ph.D.
  Senior Product Architect
  PureEdge Solutions Inc.
   

1.26 CR ISSUE: Namespace pollution of submitted instance

PROBLEM ID: 15

NOTES:

  -----Original Message-----
  From: John Boyer [mailto:JBoyer@PureEdge.com]
  Sent: Wednesday, November 27, 2002 4:03 PM
  To: w3c-forms@w3.org
  Subject: Consensus resolution of issues pertaining to namespace
  permeation from enveloping document to inline instance
  
  
  
  Below is the information necessary to amend the CR to reflect the telecon
  consensus resolution of the problems related to namespace permeation from the
  enveloping document to inline instance.
  
  Raman, I have made an effort to reduce the perception of over-specification. 
  The key descriptions are quite short, but I would like it if you could comment
  if you feel that further effort is required.
  
  Finally, note that this is not posted outside of the group, pending direction
  from the chair.  Perhaps at the next telecon we could briefly coordinate how to
  make the spec changes and provide public notification (unless the editors
  choose
  to make the spec changes below immediately and otherwise handle public
  notification).   I would be happy to help in any way with this.
  
  Thanks,
  John
  
  =========================================
  
  There are two changes:
  
  1) Clarify that namespaces are allowed to permeate into instances declared.
  2) Modify submission element so that
          a) the namespace declarations are submitted by default
          b) an attribute can be used to specify the desired namespaces to be submitted
  
  The detailed changes to the CR that are necessary to meet these requirements
  are
  
  For 1),  
  
  In Section 3.3.2, replace the following paragraph
  
  "The content of the instance element is arbitrary XML in any namespace. The
  content of this element is treated as opaque data, used to create an XPath data
  model consisting of various nodes. Authors must ensure that proper namespace
  declarations are used for content within the instance element."
  
  with
  
  "If the initial instance data is given by a link, then the instance data is
  formed by creating an XPath data model of the linked resource.
  
  If the initial instance data is given by inline content, then instance data is
  obtained by first creating a detached copy of the inline content (including
  namespaces inherited from the enveloping ancestors), then creating an XPath
  data
  model over the detached copy."
  
  For 2), 
  
  a) Example model in Section 2.1, 
          i) add xmlns="" to xforms:instance
          ii) add includenamespaces="" to xforms:submission
  
  b) Example model in Section 2.2,
          i) add xmlns="" to xforms:instance
          ii) add includenamespaces="#default" to xforms:submission
  
  c) In Section 3.3.3 (description of attributes of submission element),
          i) add attribute 'includenamespaces' of type NMTOKENS with the following
  description:
  
          For all elements being serialized for submission, the namespaces declarations
  appearing in the source file are automatically emitted.  For inline instances,
  this attribute lists those additional inherited namespace declarations that are
  to be included in the root element serialization.  If this attribute is absent
  from the submission element, then the default behavior is to emit all
  namespaces
  inherited from ancestors of the root element (in addition to those directly
  declared, but without duplication).
  
          The value of this attribute is of type NMTOKENS and contains a list of the
  namespace prefixes.  As in [Exc-C14N], if #default appears in the whitespace
  separated list, then the default namespace declaration is to be emitted.
  
  d) To the reference list, add [Exc-C14N]
  http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
  
  e) To section 11.3, serialization as application/xml, add a second list item
  
          2. The serialization is augmented slightly if the 'includenamespaces'
  attribute
  is 
                  given. See Section 3.3.3 for details.
  
  f) Appendix G
          i) In G.1, add includenamespaces="my" to the submission element
          ii) In G.3, add includenamespaces="s #default" to the submission element

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: John Boyer [mailto:JBoyer@PureEdge.com]
  Sent: Wednesday, November 13, 2002 10:53 AM
  To: www-forms-editor@w3.org
  Subject: FW: CR ISSUE: Namespace pollution of submitted instance
  
  
  
  
  
  
  -----Original Message-----
  From: John Boyer 
  Sent: Thursday, November 07, 2002 10:01 AM
  To: 'w3c-forms@w3.org'
  Subject: CR ISSUE: Namespace pollution of submitted instance
  
  
  My interpretation of the CR document is that the instance is a separate
  document, which to me includes the idea that THE INSTANCE SHOULD NOT INHERIT
  NAMESPACES available from the ancestry of the instance in the host language
  document.  
  
  Thus, the xforms namespace would not be included when serializing the
  instance for submission (unless actually declared in the instance).
  
  This is quite important to ensure that the submitted instance is capable of
  being validated by server-side schema and DTDs that are unaware of the
  envelope used to deliver the XML to the client-side.
  
  Some at the face to face were not aware of this behavior, so the spec needs
  to be clarified to make sure we have interoperable behavior.
  
  John Boyer, Ph.D.
  Senior Product Architect
  PureEdge Solutions Inc.
   

1.27 Schema for #default use in includenamespaceprefixes

PROBLEM ID: 53

NOTES:

  F2F 4 Feb 2003 - Accepted. SPEC CHANGE. (may be already done)

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: John Boyer [mailto:JBoyer@PureEdge.com]
  Sent: Thursday, December 12, 2002 12:03 PM
  To: w3c-forms@w3.org
  Subject: Schema for #default use in includenamespaceprefixes
  
  
  
  Hi all,
  
  Leigh and Micah asked me to find out why the DSig group is not using a more
  precise schema than xsd:string for its version of the
  includenamespaceprefixes attribute in exclusive c14n.  I proposed the one
  below (except for the different attribute name).  However, the general
  feeling seemed to be 
  
  1) Why is such specificity needed? 
  2) Should we be creating a rather complicated new type as an erratum?
  3) XSLT uses xsd:string.
  
  Although I don't generally agree with the first one, the second seemed to be
  a good question, and the third a good point.  Also, I added the following:
  
  4) There is some justification for xsd:string in the case of DSig in order
  to achieve symmetry with the DTD version of the type (because schema is not
  mandated, unlike XForms).
  5) The use of such specificity now would also be inconsistent with the rest
  of the DSig work, i.e. we would need to look at uniformly applying this
  level of specificity.
  
  Based on these, the dsig working group chair decided to post as 'stable' the
  erratum containing the xsd:string schema for the namespace prefix list. 
  
  However, by some of the reasoning above, it would seem that the XForms
  version of the attribute schema should be more specific, for example:
  
  <attribute name="includenamespaceprefixes">
    <simpleType>
      <list>
        <union>
          <simpleType>
              <restriction base='NCNAME'/>
          </simpleType>
          <simpleType>
            <restriction base='string'>
              <enumeration value='#default'/>
            </restriction>
          </simpleType>
        </union>
      </list>
    </simpleType>
  </attribute>
  
  This creates a whitespace-separated list that allows any NCNAME plus the
  specific word #default.
  
  John Boyer, Ph.D.
  Senior Product Architect
  PureEdge Solutions Inc.
   

1.28 submission mediatype

PROBLEM ID: 63

NOTES:

  From: Leigh.Klotz@pahv.xerox.com
  http://lists.w3.org/Archives/Member/w3c-forms/2003JanMar/0034.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Leigh.Klotz@pahv.xerox.com [mailto:Leigh.Klotz@pahv.xerox.com]
  Sent: Tuesday, January 14, 2003 8:39 AM
  To: w3c-forms@w3c.org
  Subject: submission mediatype
  
  
  
  I note that XSLT http://www.w3.org/TR/xslt#section-XML-Output-Method says
  that charset is used only for text/* and we specify application/*, so unless
  we allow 
  <submission mediatype="text/xml"/> then we should drop the language about
  charset.   Assuming so, here are the proposed changes for Action
  2002-11-26.2
  
  
  3.3.3 The submission Element
  
  mediatype
      Optional attribute (default 'application/xml') specifying the media type
  (MIME content type) of the data that results from serializing the selected
  instance nodes.
  
  NOTE: Authors should ensure that the submission mediatype attribute is
  compatible with 'application/xml', as the value of this attribute has no
  effect on the process of serialization itself, only in the Content-Type
  specified in the MIME submission.
  
  11.4 Serialization as multipart/form-data
  
        A Content-Type header specified by the submission mediatype attribute,
  or a default of "application/xml".

1.29 Canceling notification events

PROBLEM ID: 60

NOTES:

  Micah Dubinko [mdubinko@Cardiff.com]
  http://lists.w3.org/Archives/Public/www-forms-editor/2003Jan/0003.html
  
  F2F 4 Feb  2003 -- correct that any events with no default action should not be
  cancellable. Need to carefully go through list.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Micah Dubinko [mailto:mdubinko@yahoo.com]
  Sent: Saturday, January 04, 2003 9:06 PM
  To: www-forms-editor@w3.org
  Subject: Canceling notification events
  
  
  In the XForms CR, certain notification events are listed as cancelable:
  
  xforms-activate
  xforms-value-changing
  xforms-value-changed
  xforms-select
  xforms-deselect
  xforms-scroll-first
  xforms-scroll-last
  xforms-insert
  xforms-delete
  
  [the other 10 xforms-* notification events are not cancelable]
  
  What does it mean for a notification event to be canceled? How have
  implementers addressed cancelation of the above events? For instance,
  does canceling xforms-value-changed cause the value to revert back to
  what it was previously??
  
  I suggest that events that are purely for notification should never be
  cancelable, since canceling the event has no appreciable effect.
  
  As a precedent for this approach, I point to section 1.6.4 of DOM Level
  2 Events, Mutation Events, where it says:
  
  """It may be noted that none of the mutation events listed are
  designated as cancelable. This stems from the fact that it is very
  difficult to make use of existing DOM interfaces which cause document
  modifications if any change to the document might or might not take
  place due to cancellation of the related event."""
  
  I further note that the XForms events for "Error Indications" are
  uniformly non-cancelable, again since canceling the event would have no
  noticeable effect.
  
  If there are good reasons for the current approach, it would be good to
  document them somewhere.
  
  Thank you for your consideration,
  
  .micah
  
  =====
  Find out what the fuss about XForms is all about. Full text of my book
  in-progress online at http://dubinko.info/writing/xforms/
  
  __________________________________________________
  Do you Yahoo!?
  Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
  http://mailplus.yahoo.com

1.30 ANNOUNCE: FormsPlayer beta for IE 6 is now based on Candidate

PROBLEM ID: 36

NOTES:

  F2F 3/3/3 add 'mediatype' back to . Author "should"

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Klotz, Leigh [mailto:Leigh.Klotz@pahv.xerox.com]
  Sent: Wednesday, November 20, 2002 10:42 AM
  To: 'w3c-forms@w3.org'
  Subject: Discussion of CR issue for setting mediatype of submitted
  instanc e
  
  
  
  We agreed to solve this on the way out of CR, and I propose we get started
  here.
  
  I note that FormsPlayer has implemented an extension for text/xml.  
  I've sent Mark a message specifically asking for comment on this issue, for
  the SOAP use case he points out. 
  
  So far we have the following use cases:
  1. FormsPlayer extension for text/xml (use case SOAP 1.1, though not
  required for SOAP 1.2)
  2. John's request for text/xml (same use case or different?)
  3. John's and my request for + types (use case RFC 3236
  application/xhtml+xml)
  
  Case 3 is the easiest, because there is no change required in XForms
  processing or serialization, because the content can be treated the same as
  "application/xml".  Thus, I'd assume that if we add a mediatype attribute to
  submission, we can define it a allow "application/*+xml".  (We could also
  defined mediatypeextension and have it just have the "*" part, i.e.,
  mediattypeextension="xhtml", but that's not perspicacious and the attribute
  name itself is horrid in lowe case.)
  
  Case 2: We were specifically asked by I18N to avoid text/xml because of
  character set issues, we need to find out what processing or serialization
  changes would be entailed by setting the mediatype of the instance to
  text/xml.  John?
  
  Case 1: We may want to leave this alone, pending Mark's answer, since it may
  be difficult to get through SOAP 1.1 compatibility given the SOAP 1.2 status
  in W3C -- anyone else have comments on this?
  
  
  -----Original Message-----
  From: 'FormsPlayer beta' [mailto:info@x-port.net] 
  Sent: Wednesday, November 20, 2002 4:41 AM
  To: Leigh L. Klotz, Jr.
  Subject: ANNOUNCE: FormsPlayer beta for IE 6 is now based on Candidate
  Recommendation
  
  
  
  Dear Leigh L. Klotz, Jr.,
  
  x-port's FormsPlayer beta for IE 6 is now based on the XForms
  1.0 Candidate Recommendation. The new version can be downloaded
  from the FormsPlayer site:
  
          http://www.FormsPlayer.com/
  
  As well as using tags from the XForms 1.0 CR, there are quite
  a few new features, many of which are illustrated with updated
  samples. Some of these will make building internet applications
  much easier:
  
  - Saving and loading to local files is fully working. This
  allows forms to be completed offline, and then submitted at
  a later date. There is a sample that shows this, as well as
  demonstrating one technique for producing a wizard.
  
  - Using @appearance="compact" with xf:select1 and
  xf:select causes the processor to use a tree view
  control to render the items. This is very useful when
  choices are nested, since it helps guide the user in
  their selection.
  
  - The data type now influences rendering of the user
  interface. At the moment this is confined to dates, but
  more will be added.
  
  - A submission method of 'text-xml-post' has been added so
  that we can submit "text/xml" documents, which is needed for
  SOAP 1.1 applications. (SOAP 1.2 uses "application/xml+soap".)
  
  - COM interfaces have been added to the model element as
  per section 7.2, so allowing script access to the instance data
  from IE. A sample illustrates this.
  
  Regards,
  
  Mark
  
  
  
  Mark Birbeck
  Managing Director
  x-port.net Ltd.
  4 Pear Tree Court
  London
  EC1R 0DS
  
  T: +44 20 7689 9232
  W: http://www.x-port.net/
          
          

1.31 upload::filename

PROBLEM ID: 10

NOTES:

  T. V. Raman [mailto:tvraman@us.ibm.com]
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0231.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: T. V. Raman [mailto:tvraman@us.ibm.com]
  Sent: Thursday, November 07, 2002 10:25 AM
  To: w3c-forms@w3.org
  Subject: upload::filename 
  
  
  
  The spec  needs to do a better job of explaining element filename.
  
  For one thing it appears divorced from element upload making it hard
  to understand --perhaps element upload should indicate that  an
  element like filename does exist.
  
  Secondly, in the explanation of element filename, 
  nothing is said about where the filename is obtained from.
  
  With this explanation missing, and the example in the spec using a
   relative xpath locator within element filename to decide where the
  filename is placed, the reader is left with the impression that
  attribute "ref" on element filename is the thing that is selecting the
  filename -- rather than stating where the filename gets placed.
  In the least, we may need to better define the role of the binding
  attributes on element filename.
  
  
  Here is the text in question:
  
  <cite>
  
  This optional element provides a way for the upload form control to insert a
  filename, when available, that represents the chosen binary resource.
  
  Common Attributes: Common, Single Node Binding
  
  This specification does not define the format of a filename.
  
  Example:
   <upload ref="mail/attachment" mediatype="image/*">
    <label>Select an attachment</label>
    <filename ref="../filename"/>
    <mediatype ref="@type"/>
  </upload>
  
  
  In this example, the user is prompted to select an image of some sort. The
  binary data of the image is placed under the element node selected by
  "mail/attachment". The filename, perhaps "
  /home/mdubinko/data/pictures/me.jpg", is placed under the element node
  selected by "mail/filename", and the mediatype, perhaps "image/jpeg" is
  placed
  under the attribute node at "mail/attachment/@type".
  
  </cite>
  
  -- 
  Best Regards,
  --raman
  ------------------------------------------------------------
  T. V. Raman:  PhD (Cornell University)
  IBM Research: Human Language Technologies
  Architect:    Conversational And Multimodal WWW Standards
  Phone:        1 (408) 927 2608   T-Line 457-2608
  Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
  Email:        tvraman@us.ibm.com
  WWW:      http://www.cs.cornell.edu/home/raman
  AIM:      TVRaman
  PGP:          http://emacspeak.sf.net/raman.asc
  Snail:        IBM Almaden Research Center,
                650 Harry Road
                San Jose 95120

1.32 [8.1.6] possible typo in mediatype attribute

PROBLEM ID: 17

NOTES:

  T. V. Raman [mailto:tvraman@us.ibm.com]
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0292.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: T. V. Raman [mailto:tvraman@us.ibm.com]
  Sent: Wednesday, November 13, 2002 1:52 PM
  To: w3c-forms@w3.org
  Subject: [8.1.6] possible typo in mediatype attribute 
  
  
  
  <cite>
  mediatype
            Space-separated list of suggested media types, used by the XForms
       Processor to determine which input methods apply.</cite>
  
  I suspect the "which input methods apply" is a consequence of cut and
  paste.
  
  -- 
  Best Regards,
  --raman
  ------------------------------------------------------------
  T. V. Raman:  PhD (Cornell University)
  IBM Research: Human Language Technologies
  Architect:    Conversational And Multimodal WWW Standards
  Phone:        1 (408) 927 2608   T-Line 457-2608
  Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
  Email:        tvraman@us.ibm.com
  WWW:      http://www.cs.cornell.edu/home/raman
  AIM:      TVRaman
  PGP:          http://emacspeak.sf.net/raman.asc
  Snail:        IBM Almaden Research Center,
                650 Harry Road
                San Jose 95120

1.33 XForms CR - sections 9.3.5 to 9.3.7=20

PROBLEM ID: 18

NOTES:

  F2F 3/3/3 Add hyperlink from Actions chapter.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  This message is in MIME format. Since your mail reader does not understand
  this format, some or all of this message may not be legible.
  
  ------_=_NextPart_000_01C295DF.F8DC54B0
  Content-Type: text/plain;
          charset="iso-8859-1"
  Content-Transfer-Encoding: quoted-printable
  
  
  
  -----Original Message-----
  From: Roman Huditsch [mailto:roman.huditsch@hico.com]
  Sent: Thursday, November 14, 2002 5:13 AM
  To: www-forms@w3.org
  Subject: XForms CR - sections 9.3.5 to 9.3.7=20
  
  
  Hi,
  
  regarding sections 9.3.5 to 9.3.7 I wonder why these actions (insert,
  delete, setIndex) are all described in 9.3 (the repeat module) and not =
  in
  chapter 10 where all other actions are explained. Is there a specific =
  reason
  for that? As I am a rather casual reader of the specification I would =
  find
  it better to have all actions available in one single chapter. But =
  maybe I
  am missing a point.
  
  wbr,=20
  Roman Huditsch (hRHU )
  Developer .:. Information & Application Engineering=20
  _____________________________________________________________________
  hico Informations- und Kommunikations-Management Gesellschaft m.b.H.
  TechLab, Thomas A. Edison Stra=DFe 2.
  A-7000 Eisenstadt / Austria
  phone: +43/2682/704-61-73; fax: +43/2682/704-71-61-10
  e-mail: roman.huditsch@hico.com
  mobile: +43/664/4102715
  
  
  
  ------_=_NextPart_000_01C295DF.F8DC54B0
  Content-Type: text/x-vcard;
          name="Roman Huditsch.vcf"
  Content-Disposition: attachment;
          filename="Roman Huditsch.vcf"
  
  BEGIN:VCARD
  VERSION:2.1
  N:Huditsch;Roman
  FN:Roman Huditsch
  EMAIL;PREF;INTERNET:roman.huditsch@hico.com
  REV:20020717T130358Z
  END:VCARD
  
  ------_=_NextPart_000_01C295DF.F8DC54B0--

1.34 Typo in 10.1.7

PROBLEM ID: 20

NOTES:

  T. V. Raman [mailto:tvraman@us.ibm.com]
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0299.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: T. V. Raman [mailto:tvraman@us.ibm.com]
  Sent: Thursday, November 14, 2002 10:52 AM
  To: w3c-forms@w3.org
  Subject: Typo in 10.1.7
  
  
  
  <cite>
  10.1.7 The setfocus Element
  
  This action sets focus to the form control referenced by the idref
  attribute
  </cite>
  Change "idref attribute" to 
  attribute <attr>control</attr>
  
  -- 
  Best Regards,
  --raman
  ------------------------------------------------------------
  T. V. Raman:  PhD (Cornell University)
  IBM Research: Human Language Technologies
  Architect:    Conversational And Multimodal WWW Standards
  Phone:        1 (408) 927 2608   T-Line 457-2608
  Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
  Email:        tvraman@us.ibm.com
  WWW:      http://www.cs.cornell.edu/home/raman
  AIM:      TVRaman
  PGP:          http://emacspeak.sf.net/raman.asc
  Snail:        IBM Almaden Research Center,
                650 Harry Road
                San Jose 95120

1.35 RE: [8.1.6] possible typo in mediatype attribute

PROBLEM ID: 21

NOTES:

  F2F 3/3/3 change "which input methods apply" to "which type of media can be
  uploaded"

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Klotz, Leigh [mailto:Leigh.Klotz@pahv.xerox.com]
  Sent: Friday, November 15, 2002 12:04 PM
  To: 'tvraman@almaden.ibm.com'; 'Micah Dubinko'
  Cc: 'w3c-forms@w3.org'
  Subject: RE: [8.1.6] possible typo in mediatype attribute 
  
  
  It's explained pretty well in the "Implementation Requirements" section in
  8.1.6.
  How about "to determine sources of data to upload".
  
  ALSO, I noticed that anyURI was removed from the list of allowed binding
  types.
  
  -----Original Message-----
  From: T. V. Raman [mailto:tvraman@us.ibm.com] 
  Sent: Wednesday, November 13, 2002 4:51 PM
  To: Micah Dubinko
  Cc: 'tvraman@almaden.ibm.com'; w3c-forms@w3.org
  Subject: RE: [8.1.6] possible typo in mediatype attribute 
  
  
  
  
  I dont know.
  the current text just didn't make sense as I reviewed it while writing
  the relevant test case.
  
  In stead of "which input modes " apply we may have meant "which
  resources are available to upload" or something similar.
  >>>>> "Micah" == Micah Dubinko <MDubinko@cardiff.com> writes:
  
  
      Micah> What do you propose changing it to? -m -----Original
      Micah> Message----- From: T. V. Raman [mailto:tvraman@us.ibm.com]
      Micah> Sent: Wednesday, November 13, 2002 1:52 PM To:
      Micah> w3c-forms@w3.org Subject: [8.1.6] possible typo in
      Micah> mediatype attribute
  
  
  
      Micah> <cite> mediatype Space-separated list of suggested media
      Micah> types, used by the XForms Processor to determine which
      Micah> input methods apply.</cite>
  
      Micah> I suspect the "which input methods apply" is a consequence
      Micah> of cut and paste.
  
      Micah> -- Best Regards, --raman
      Micah> ------------------------------------------------------------
      Micah> T. V. Raman: PhD (Cornell University) IBM Research: Human
      Micah> Language Technologies Architect: Conversational And
      Micah> Multimodal WWW Standards Phone: 1 (408) 927 2608 T-Line
      Micah> 457-2608 Fax: 1 (408) 927 3012 Cell: 1 650 799 5724 Email:
      Micah> tvraman@us.ibm.com WWW:
      Micah> http://www.cs.cornell.edu/home/raman AIM: TVRaman PGP:
      Micah> http://emacspeak.sf.net/raman.asc Snail: IBM Almaden
      Micah> Research Center, 650 Harry Road San Jose 95120
  
  -- 
  Best Regards,
  --raman
  ------------------------------------------------------------
  T. V. Raman:  PhD (Cornell University)
  IBM Research: Human Language Technologies
  Architect:    Conversational And Multimodal WWW Standards
  Phone:        1 (408) 927 2608   T-Line 457-2608
  Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
  Email:        tvraman@us.ibm.com
  WWW:      http://www.cs.cornell.edu/home/raman
  AIM:      TVRaman
  PGP:          http://emacspeak.sf.net/raman.asc
  Snail:        IBM Almaden Research Center,
                650 Harry Road
                San Jose 95120

1.36 CR 8.1.3 Secret

PROBLEM ID: 22

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 6:50 PM
  To: www-forms-editor@w3.org
  Subject: CR 8.1.3 Secret
  
  
  
  
  "In general, implementations, including accessibility aids, must render a
  "*" or similar character instead of the actual characters entered, and thus
  must not render the entered value of this form control."
  
  Delete "in general"
  

1.37 8.1.5 output

PROBLEM ID: 23

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 6:52 PM
  To: www-forms-editor@w3.org
  Subject: 8.1.5 output
  
  
  
  
  It is typically used to display values from the instance, and is treated as
  display:inline for purposes of layout. [[delete "typically"]]
  

1.38 8.1.6 upload

PROBLEM ID: 24

NOTES:

  Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Nov/0061.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 6:53 PM
  To: www-forms-editor@w3.org
  Subject: 8.1.6 upload
  
  
  
  
  "The types of files presented by default must reflect the mediatype
  specified in the XForms Model, for example defaulting to only audio file
  types in the file dialog when the mediatype is "audio/*". In XForms 1.0,
  there is a 1:1 binding between a upload form control and one of the binary
  datatypes, although that single file may be compound (e.g. application/zip).
  "
  
  [[Is this really a Must?]]
  

1.39 8.3.1 filename

PROBLEM ID: 25

NOTES:

  Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Nov/0062.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 6:54 PM
  To: www-forms-editor@w3.org
  Subject: 8.3.1 filename
  
  
  
  
  [[vague]] This optional element provides a way for the upload form control
  to insert a filename, when available, that represents the chosen binary
  resource.
  

1.40 CR Section 8.3 errors

PROBLEM ID: 16

NOTES:

  F2f 3/3/3 spec change accepted

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Alex Rosen [mailto:arosen@novell.com]
  Sent: Wednesday, November 13, 2002 11:48 AM
  To: www-forms@w3.org
  Subject: CR Section 8.3 errors
  
  
  
  Sections 8.3.4 and 8.3.5 talk about xforms:help and xforms:hint events,
  these should be xforms-help and xforms-hint. They also both talk about the
  "type" attribute on <message>, this should be "level".
  
  Since "hint" corresponds to "ephemeral" and "help" corresponds to
  "modeless", it seems logical to conclude that "alert" corresponds to
  "modal". If this isn't true, it would be helpful to explicitly state this
  fact in section 8.3.6, to keep from leading people down the garden path.
  
  Also, in the same section, "at in instance data" has one too many words.
  
  Alex Rosen
  Novell, Inc.
  

1.41 8.3.2 mediatype

PROBLEM ID: 26

NOTES:

  Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Nov/0063.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 6:55 PM
  To: www-forms-editor@w3.org
  Subject: 8.3.2 mediatype
  
  
  
  
  (must???)[[vague]] This optional element provides a way for the upload form
  control to insert a mediatype, when available, that represents the chosen
  binary resource.
  

1.42 8.1.7 range

PROBLEM ID: 27

NOTES:

  Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Nov/0064.html
  
  Notes from resolution of 10 December 2002 meeting:
  
  Two changes:
  
  Resolution 2002-12-10.9
  change "should" to "must"
  
  Resolution 2002-12-10.10
  change "hint" to "the user agent may"
  
  See Leigh's minutes of 10 Dec for details

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 6:56 PM
  To: www-forms-editor@w3.org
  Subject: 8.1.7 range
  
  
  
  
  (should??) step Optional hint to use for incrementing or decrementing the
  value. Should be of a type capable of expressing the difference between two
  legal values of the underlying data. [[Should => must]]
  

1.43 8.1.11 select1

PROBLEM ID: 28

NOTES:

  Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Nov/0065.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 6:57 PM
  To: www-forms-editor@w3.org
  Subject: 8.1.11 select1
  
  
  
  
  The value to be stored is either directly specified as the contents of
  element value, or specified indirectly through binding attributes on element
  value. [[order of which to choose?]]
  

1.44 9.1.1 group

PROBLEM ID: 29

NOTES:

  Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Nov/0066.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 6:58 PM
  To: www-forms-editor@w3.org
  Subject: 9.1.1 group
  
  
  
  
  [[needs to be stronger]] The binding expression is solely for the purpose of
  authoring convenience; it allows controls appearing within element group to
  use relative XPath expressions.
  

1.45 9.1.1 group

PROBLEM ID: 30

NOTES:

  Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Nov/0067.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 6:59 PM
  To: www-forms-editor@w3.org
  Subject: 9.1.1 group
  
  
  
  
  (must? vague) The label element has special significance when it appears as
  the first element child of group, representing a label for the entire group.

1.46 9.3.1 repeat

PROBLEM ID: 31

NOTES:

  Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Nov/0068.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 7:00 PM
  To: www-forms-editor@w3.org
  Subject: 9.3.1 repeat
  
  
  
  
  [[shouldn't be a must]] In the absence of this attribute, all elements of
  the collection are displayed.

1.47 9.3.4 copy

PROBLEM ID: 32

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 7:01 PM
  To: www-forms-editor@w3.org
  Subject: 9.3.4 copy
  
  
  
  
  A full computational dependency rebuild.[[is done]]

1.48 9.3.4 copy

PROBLEM ID: 33

NOTES:

  Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Nov/0069.html

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 7:02 PM
  To: www-forms-editor@w3.org
  Subject: 9.3.4 copy
  
  
  
  
  A full computational dependency rebuild.[[is done]]
  

1.49 9.3.10 User Interface Interaction

PROBLEM ID: 34

NOTES:

  Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  http://lists.w3.org/Archives/Public/www-forms-editor/2002Nov/0071.html
  
  
  Resolution 2002-12-10.14
  should be changed to "when changed items should be presented"
  Sebastian: I agree

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Steven Pemberton [mailto:steven.pemberton@cwi.nl]
  Sent: Monday, November 18, 2002 7:06 PM
  To: www-forms-editor@w3.org
  Subject: 9.3.10 User Interface Interaction
  
  
  
  
  The current item indicated by the repeat index should be presented at all
  times, for example, not allowed to scroll out of view.[[presented=>visible]]
  
  The XForms Actions enumerated at 10 XForms Actions may be used within event
  listeners to manipulate the homogeneous collection being populated by
  scrolling, inserting, and deleting entries. [[at 10 => in 10]]
  

1.50 [repeat] spec edit

PROBLEM ID: 52

NOTES:

  Accepted. SPEC CHANGE (may be done already)

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: T. V. Raman [mailto:tvraman@us.ibm.com]
  Sent: Sunday, December 15, 2002 11:19 AM
  To: w3c-forms@w3.org
  Subject: [repeat] spec edit 
  
  
  
  <cite>
  number
            Optional hint to the XForms Processor as to how many elements from
       the collection to display. In the absence of this attribute, all
  elements
       of the collection are displayed.
  </cite>
  
  should be changed to 
  "in the absence of this attribute the user agent decides how many
  elements to display.
  
  -- 
  Best Regards,
  --raman
  ------------------------------------------------------------
  T. V. Raman:  PhD (Cornell University)
  IBM Research: Human Language Technologies
  Architect:    Conversational And Multimodal WWW Standards
  Phone:        1 (408) 927 2608   T-Line 457-2608
  Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
  Email:        tvraman@us.ibm.com
  WWW:      http://www.cs.cornell.edu/home/raman
  AIM:      TVRaman
  PGP:          http://emacspeak.sf.net/raman.asc
  Snail:        IBM Almaden Research Center,
                650 Harry Road
                San Jose 95120

1.51 What happens if a form control violates Data Binding

PROBLEM ID: 62

NOTES:

  [mailto:Leigh.Klotz@pahv.xerox.com]
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0504.html
  
  F2F 4 Feb 2003 - after discussion, decided that not meeting datatype constraints
  causes irrelevant (as when node doesn't exist/form-control-initialize). SPEC
  CHANGE.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Klotz, Leigh [mailto:Leigh.Klotz@pahv.xerox.com]
  Sent: Monday, December 16, 2002 5:33 PM
  To: 'w3c-forms@w3.org'
  Subject: What happens if a form control violates Data Binding
  Restrictions ?
  
  
  
  We don't say what to do when a form control does not meet the data binding
  restrictions.
  For example, if you bind a range to a string node, what happens?
  John Keiser and I thought the input control ought to be invalid.
  X-Smiles 20021216 nightly renders it as an <input>.
  Novell xPlorer gets a terminating error (Java backtrace).
  
  It's presumably an authoring problem if the restrictions are violated (at
  least the restrictions I can think of -- maybe there are some dynamic ones
  in the complex type case or something), so it's possible that we should just
  say "terminating error," but it sure would be nice to have some feedback
  about what's wrong.  Otherwise it's hard to author; as us authors are
  finding...

2. NothingToDo

2.1 XForms CR - 6.1.6 constraint property

PROBLEM ID: 19

NOTES:

  Roman Huditsch [mailto:roman.huditsch@hico.com]
  
  Micah notes that the example is correct; the < operator converts the operands.
  Not sent to www-forms-editor. Replying on www-forms.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  This message is in MIME format. Since your mail reader does not understand
  this format, some or all of this message may not be legible.
  
  ------_=_NextPart_000_01C295DF.FEBCD8F0
  Content-Type: text/plain;
          charset="iso-8859-1"
  Content-Transfer-Encoding: quoted-printable
  
  
  
  -----Original Message-----
  From: Roman Huditsch [mailto:roman.huditsch@hico.com]
  Sent: Thursday, November 14, 2002 5:19 AM
  To: www-forms@w3.org
  Subject: XForms CR - 6.1.6 constraint property
  
  
  Hi again,
  
  The example within section 6.1.6 "the constraint property" seams a =
  little
  bit odd to me, bacause I can't imagine how or better say why (in that =
  case)
  the processer should compare two string values with a "greater than"
  operator.=20
  Wouldn't it be better to say "!=3D"?
  
  wbr,
  Roman Huditsch (hRHU )
  Developer .:. Information & Application Engineering=20
  _____________________________________________________________________
  hico Informations- und Kommunikations-Management Gesellschaft m.b.H.
  TechLab, Thomas A. Edison Stra=DFe 2.
  A-7000 Eisenstadt / Austria
  phone: +43/2682/704-61-73; fax: +43/2682/704-71-61-10
  e-mail: roman.huditsch@hico.com
  mobile: +43/664/4102715
  
  
  
  ------_=_NextPart_000_01C295DF.FEBCD8F0
  Content-Type: text/x-vcard;
          name="Roman Huditsch.vcf"
  Content-Disposition: attachment;
          filename="Roman Huditsch.vcf"
  
  BEGIN:VCARD
  VERSION:2.1
  N:Huditsch;Roman
  FN:Roman Huditsch
  EMAIL;PREF;INTERNET:roman.huditsch@hico.com
  REV:20020717T130358Z
  END:VCARD
  
  ------_=_NextPart_000_01C295DF.FEBCD8F0--

2.2 RE: CR ISSUE: Incorrect XPath Initial Context

PROBLEM ID: 14

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: John Boyer [mailto:JBoyer@PureEdge.com]
  Sent: Friday, November 08, 2002 4:42 PM
  To: Micah Dubinko; w3c-forms@w3.org
  Subject: RE: CR ISSUE: Incorrect XPath Initial Context
  
  
  
  
  -----Original Message-----
  From: Micah Dubinko [mailto:MDubinko@cardiff.com]
  Sent: Thursday, November 07, 2002 11:57 AM
  To: John Boyer; w3c-forms@w3.org
  Subject: RE: CR ISSUE: Incorrect XPath Initial Context
  
  
  On bullet 5, can you show an example of an expression affected by this
  proposed change?
  
  <jb>
  Not the greatest, but I'm a little pressed for time:
  
  constraint="if(string(.)!='', true(), if(position()=last(), true(),
  false()))"
  </jb>
  
  Thanks!
  
  .micah

2.3 CR ISSUE: section 4.2.2 bullet 2

PROBLEM ID: 41

NOTES:

  F2F 3/3/3 Spec already changed

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Kenneth Sklander [mailto:ksklander@novell.com]
  Sent: Wednesday, November 27, 2002 4:47 AM
  To: w3c-forms@w3c.org
  Subject: CR ISSUE: section 4.2.2 bullet 2
  
  
  
  The instance data is constructed during 4.2.1 bullet 2.

2.4 Re: Possible CR issue: schema validation versus relevant

PROBLEM ID: 49

NOTES:

  Kenneth Sklander (ksklander@novell.com)
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0451.html
  
  John Boyer started this thread by asking "why should the whole instance be
  schema valid before I can submit anything if my submission only submits a
  subtree?"
  
  Kenneth's response (originating this issue) had further substantive
  implementation issues.
  
  F2F 4 Feb 2003 -- Agreed future.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: David Landwehr [mailto:DLandwehr@novell.com]
  Sent: Friday, December 06, 2002 12:30 AM
  To: Leigh.Klotz@pahv.xerox.com; w3c-forms@w3c.org
  Subject: Re: Possible CR issue: schema validation versus relevant
  subtree *submission
  
  
  
  11.1 (step 1) says that only the relevant part of the selected instance is
  considered for the submission. I would mean that only the relevant nodes are
  considered in revalidation (as step 2 says "All selected instance data is
  revalidated", which would mean validation is only performed on the nodes
  that are actually going to be serialized). 
  
  This however gives a little problem in the case where the selected node (the
  root element) has an anonymous complex type in the instance with the same
  name as a global defined type. The datatype of the child nodes of this root
  element could be schema valid using the anonymous type but not using the
  global type. Then the user cannot submit data which appears to be valid (the
  bound controls is at least valid).
  
  Of course this would be a bad authored form, but the user would never be
  able to be notified about the reason for not submitting. The same applies if
  the structure is invalid because of relevance. It seems no form controls can
  bind to mixed content and therefore xforms-invalid and xforms-valid will
  never be dispatched in the form when doing structural validation.
  
  Question: how is a user supposed to be notified about structural errors? 
  
  /David
  
  
  >>> "Leigh L. Klotz Jr" <Leigh.Klotz@pahv.xerox.com> 05-12-02 20:39 >>>
  
  John,
  Comments inlined below.
  Leigh.
        Date: Thu, 5 Dec 2002 17:04:53 -0800
      Message-ID:
      <7874BFCCD289A645B5CE3935769F0B52452866@tigger.pureedge.com>
      From: "John Boyer" <JBoyer@PureEdge.com>
      To: <w3c-forms@w3.org>
      Subject: Possible CR issue: schema validation versus relevant
      subtree submission
      
      
      
      The submission processing model (Section 11.1) says that the
      instance will be schema validated (step 2) before serialization
      (step 3).  
      
      But why should the whole instance be schema valid before I can
      submit anything if my submission only submits a subtree?
  Yes, only the submitted portion of the instance must be valid.
  
      Orthogonally, what if the instance is structurally schema valid, but
      the relevant portion that will be serialized for submission is not?
  I don't see how this could happen, since you cannot say "X occurs only
  in Y" in a Schema; validity is top-up, not bottom down.
      
      Would it be better to serialize first, then schema validate the
      result?
  Like Raman said, and you suggested above, we should say to validate the
  subtree that's about to be submitted.
      
      By the way, I assume that we choose a schema by matching the
      targetnamespace of the schema to the namespace of the *root element*
      (of the instance for now, but perhaps it should be the root of the
      submission).  Can anyone confirm this?
  (I don't mean to be pedantic, but warning bells go off any time there is
  a sentence that has "root element" and "XML Schema" in it.)
  All the Schemas in the model schema list and in the xsd:schema child
  elements of model must be used.  Each xsd:schema has one targetNamespace
  attribute and elements in that namespace are validated against the
  corresponding Schema.  
  
  At one point I had proposed allowing any number of Schemas without
  regard to their namespaces, but many Schema processors APIs do not allow
  this (Microsoft .NET for example) and if you go by the markup
  interfaces, the Schema spec allows only one Schema per namespace as well
  (so it appears).  The Novell implementation uses its own Schema
  processor and does this last step for you automatically if you give it
  multiple Schemas by its API, but for interoperability in XForms we've
  specified only one Schema (either included or inline) per namespace.
      
  
  
  
  

2.5 Spec unclarity: is output value="xpath" dynamic?

PROBLEM ID: 48

NOTES:

  Mikko Honkala [honkkis@tml.hut.fi]
  http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/0446.html
  
  Kenneth adds:
  "We think that the dependent nodes and functions of the value should be
  calculated dynamicly.
  
  Furthermore the evaluation context of the value, should be the same as that
  of the ref."
  
  Also, questions on whether dynamic dependencies are allowed in 'value'.
  
  
  F2F 4 Feb 2003 -- Accepted; already changed.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Mikko Honkala [mailto:honkkis@tml.hut.fi]
  Sent: Thursday, December 05, 2002 5:32 AM
  To: w3c-forms@w3c.org
  Subject: Spec unclarity: is output value="xpath" dynamic?
  
  
  
  Hi,
  
  the CR spec seems to be unclear whether the "value" attribute is dynamic 
    or not.
  
  8.1.5 The output Element just says:
  
  "it can also be used to display the result of evaluating an XPath 
  expression by specifying the XPath expression to be evaluated via 
  attribute value instead of ref"
  
  We have to make sure that implementors/author understand that this XPath 
  expression is evaluated every time a referred node changes. (I don't 
  know about other implementors, but I will actually make this part of the 
  calculation engine).
  
  So proposed addition: "The XPath expression in attribute value is 
  executed dynamically whenever there is a change in a node that the 
  expression refers to."
  
  By the way, are dynamic dependencies allowed there? I'd say no, since 
  they are now allowed in model item properties.
  
  -mikko

2.6 evaluation context contradiction

PROBLEM ID: 54

NOTES:

  duplicate of earlier issue (48)

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Paul Butcher [mailto:Paul.Butcher@x-port.net]
  Sent: Tuesday, December 03, 2002 8:01 AM
  To: 'www-forms@w3.org'
  Subject: evaluation context contradiction
  
  
  
  There seems to be a contradiction in the current XForms spec regarding the
  evaluation context for XPath expressions in model item properties.  Consider
  the following two excerpts:
  
  (a) http://www.w3.org/TR/2002/CR-xforms-20021112/slice4.html#evt-recalculate
  
  states:
  When it is time to recalculate a compute, the XPath expression is evaluated
  in the context of the instance node whose value or model item property is
  associated with the compute.
  
  (b) http://www.w3.org/TR/2002/CR-xforms-20021112/slice7.html#expr-eval
  Point 4 states:
   The context node for computed expressions (occurring on element bind) is
  the first node of the node-set returned from the binding expression in the
  nodeset attribute on the same element.
  
  Both of the rules define different context nodes for the evaluation of XPath
  in model item property attributes.
  
  The problem:
  
  Given the following model definition:
  <xf:model id="m1">
          <xf:instance>
                  <x>
                          <y>a very, very long string indeed</y>
                          <y>short string</y>
                  </x>
          </xf:instance>
          <xf:bind nodeset="y" constraint="string-length(.) &lt; 15" /> 
  </xf:model>
  
  And the following two elements:
  
  <xf:output model="m1" ref="y[1]" id="o1" />
  <xf:output model="m1" ref="y[2]" id="o2" />
  
  If the rule at (a) above is applied, both outputs would be marked as invalid
  at the start, until the content of the first <y> element is sufficiently
  shortened.
  
  If the rule at (b) above is applied, then output "o1" would be marked as
  invalid, and the output "o2" valid.
  
  If they are both correct, then both outputs would be marked as invalid until
  a recalculate is forced, at which point the output "o2" would become valid.
  However, since "xforms-recalculate" occurs during "xforms-model-initialize"
  processing, the rule at (b) is redundant, because there is no situation in
  which a computed expression is evaluated outside the processing of
  "xforms-recalculate"
  
  For the next version of Formsplayer, we have assumed that (a) is the correct
  behaviour, that the context node for model item properties is the node with
  which the property is associated.
  
  
  Paul Butcher
  FormsPlayer Lead Programmer
  x-port.net Ltd.
  4 Pear Tree Court
  London
  EC1R 0DS
  
  Try our XForms plug-in for IE
  at http://www.FormsPlayer.com/

2.7 7.2 XForms DOM interfaces are specified strangely

PROBLEM ID: 59

NOTES:

  Micah Dubinko [mdubinko@Cardiff.com]
  http://lists.w3.org/Archives/Public/www-forms-editor/2003Jan/0000.html
  
  F2F 4 Feb 2003 - Rejected, no change.

ORIGINAL MESSAGE:

  From: Micah Dubinko <MDubinko@cardiff.com>
  
  
  
  -----Original Message-----
  From: Micah Dubinko [mailto:mdubinko@yahoo.com]
  Sent: Wednesday, January 01, 2003 4:17 PM
  To: www-forms-editor@w3.org
  Subject: 7.2 XForms DOM interfaces are specified strangely
  
  
  
  
  Greetings,
  
  Upon review of the DOM interfaces defined in 7.2, there are some
  seeming inconsistencies, or at least oddities. As currently specified,
  code such as this (JavaScript in this case) would be needed to modify
  instance data through script:
  
  var modelElem = document.getElementById("id_of_model_element");
  var instDoc = modelElem.getInstanceDocument("id_of_instance_element"); 
  
  // Perform operations on instDoc
  
  modelElem.rebuild();
  modelElem.recalculate();
  modelElem.revalidate();
  modelElem.refresh();
  
  The strange part is that the interface is based on the model element,
  so another idref is needed in the parameter of getInstanceDocument to
  say _which_ instance is needed, within the model. If my recollection
  serves, this goes back to the time when each model had only a single
  instance.
  
  Further, the four r* methods will cause *all* instances on the given
  model to be rebuilt/recalculated/revalidated/refreshed, which is a
  different level of granularity than getInstanceDocument.
  
  Request: If the implementers agree, I request that the interface be
  specified as part of the instance element instead, removing the need
  for a parameter on getInstanceData. The previous code would then look
  like:
  
  var instElem = document.getElementById("id_of_instance_element");
  var instDoc = modelElem.getInstanceDocument(); 
  
  // Perform operations on instDoc
  
  instElem.rebuild();
  instElem.recalculate();
  instElem.revalidate();
  instElem.refresh();
  
  Thanks,
  
  .micah
  
  =====
  Find out what the fuss about XForms is all about. Full text of my book
  in-progress online at http://dubinko.info/writing/xforms/
  
  __________________________________________________
  Do you Yahoo!?
  Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
  http://mailplus.yahoo.com