- From: Nick Van den Bleeken <Nick_Van_den_Bleeken@inventivegroup.com>
- Date: Wed, 13 Jan 2010 14:49:05 +0100
- To: John Boyer <boyerj@ca.ibm.com>, "Klotz, Leigh" <Leigh.Klotz@xerox.com>
- CC: Forms WG <public-forms@w3.org>
- Message-ID: <98F519CDC2FA6146AE00069E9A1D91FD8706041AEF@erganix.dc.intranet>
The only problem I see with having xforms.anyElement? is that you can't put any xml comment before your instance 'document element' and after it. It looks like that wasn't supported before either.... Regards, Nick Van den Bleeken R&D Manager Phone: +32 3 821 01 70 Office Fax: +32 3 821 01 71 Nick_Van_den_Bleeken@inventivegroup.com<mailto:Nick_Van_den_Bleeken@inventivegroup.com> http://www.inventivedesigners.com<http://www.inventivedesigners.com/> From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of John Boyer Sent: maandag 11 januari 2010 23:18 To: Klotz, Leigh Cc: Forms WG Subject: Re: XForms 1.1 RNC Schema xf:instance Hi Leigh, I agree. I don't know why it would say anyElement* since if you put more than one element, processing will halt with an exception anyway. If there is a src attribute, it takes precedence over inline content, so perhaps there "should" be nothing there, but you don't get an exception if there is, so there is not a real need to enforce it. There is an analogous co-occurrence constraint with resource, but it works the other way around. If there is inline content, then the resource attribute is ignored. So one might be inclined to say there should not be a resource attribute if there is inline content. However, the reason I advocated for the resource attribute is so that a document (e.g. ODF, XFDL or even prepopulated HTML) could be responsive to state other than the initial empty states without having to modify the part of the document associated with the "application" description, which may be digitally signed. So, it is expected that inline instance data and the resource attribute can co-exist and that the well-defined precedence order indicates what to do. It is not unreasonable, then, to take the same approach for handling co-occurrence of src and inline data. Cheers, John M. Boyer, Ph.D. STSM, Lotus Forms Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw From: "Klotz, Leigh" <Leigh.Klotz@xerox.com> To: "Forms WG" <public-forms@w3.org> Date: 01/11/2010 10:04 AM Subject: XForms 1.1 RNC Schema xf:instance ________________________________ We should change xforms.instance.content = xforms.anyElement* to xforms.instance.content = xforms.anyElement? There may lexical co-occurrence constraints with @src but there are none with @resource so I believe this change is sufficient. Leigh. ________________________________ From: Owen Newnan [mailto:onewnan@gmail.com] Sent: Saturday, January 09, 2010 5:56 PM To: Klotz, Leigh Subject: invalid instance data? Leigh, I get the message Chapt03/3.3/3.3.2/3.3.2.g.xhtml:11:20: cvc-complex-type.2.4.d: Invalid content was found starting with element 'numberB'. No child element is expected at this point. I think this message is right, the spec says 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. The detached copy must consist of content that would be well-formed XML if it existed in a separate document. Note that this restricts the element content of instance to a single child element. However, I get no err on the RNC side. Same thing with 3.3.2.h.xhtml. -- Best, Owen Newnan cell 720 260-5753 home 303 697 1925 http://www.linkedin.com/in/OwenNewnan -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- ________________________________ Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --
Received on Wednesday, 13 January 2010 13:49:53 UTC