W3C home > Mailing lists > Public > public-forms@w3.org > January 2010

RE: XForms 1.1 RNC Schema xf:instance

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:53 UTC