RE: Control heirarchies

Hi again Micah,

At 04:07 PM 11/5/2001 -0800, Micah Dubinko wrote:
>Hi Jim,
>
> >But, unless I'm missing something, my app:application containing framework
> >is no more un-compliant than an xhtml doc with multiple interlinked pages,
> >built in whatever way the designer decides, and with whatever resources are
>
> >at their disposal, that are interspersed with controls.  Is this a true
> >statement?
>
>No, I think there's a difference.
>
>The difference is, as far as I can tell, that the XForms specification
>defines concrete rules for how XForms Processors deal with ref (and nodeset)
>attributes--how to determine the context in which the XPath expression is
>evaluated.
>
>In HTML, none of these rules are changed or supplimented.

So, if I understand, a compliant xforms processor must examine all 
elements, independent of namespace or node name, to see if they have an 
attribute "ref" or "nodeset"?  This seems like a recipe for disaster to 
me.  The fact that you say HTML or XHTML doesn't specify these indicates 
strongly to me that special consideration IS in fact being given towards 
specific containers (and there may be good reason for this - I fully 
acknowledge my lack of background in the working group's motivating 
factors, goals and other constraints). Because otherwise, it surely can't 
be expected that no container will have to use an attribute named "ref" for 
its own arbitrary purposes?  What about a hypothetical SOAP service that 
returns an envelope with an xform and a data instance, as part of a 
workflow, where a SOAP intermediary defines an element with "ref" for an 
attribute?  Is there a reason that it doesn't look for these attributes 
only in elements with the xforms namespace?

That being said (and I assume I'm just missing something), if I change my 
attribute names to something else, like "aref", then does that fix my 
compliance issues (wrt this item)?

>Your example used an element <app:table ref="addressBook/person">, in what
>seems to be a parallel construction to <xforms:repeat>. The XForms element
>applies special processing, similar to <for-each> in XSLT. If the intent is
>for the <app:table> element to provide similar special processing, then we
>get into muddy conformance waters.

But why is the fact that this is similar of any consequence?  It's in a 
different namespace with different tag names.  A processor shouldn't care 
if it's <app:table> or <boogie:oogie-oogie>, right?  If it sees a tag that 
isn't specifically it's own, it seems it should just be ignored.

Anyway, The repeat structure I have had to mirror for other reasons that 
I'll save for another day, so you don't hate me too bad!  :)

>I hope this is helpful. :-) It's possible I'm missing the point completely.
>Thanks,
>
>.micah

It definitely is helpful, I'm learning as we go.  Most likely that I'm 
missing something.

Thanks,
Jim




>-----Original Message-----
>From: Jim Wissner [mailto:jim@jbrix.org]
>Sent: Monday, November 05, 2001 12:46 PM
>To: Micah Dubinko
>Subject: RE: Control heirarchies
>
>
>
>Hi Micah,
>
>At 12:24 PM 11/5/2001 -0800, you wrote:
> >Hi Jim,
> >
> >In your example, <app:table ref="addressBook/person"> has a 'ref' attribute
> >that looks much like the XForms 'ref' attribute, but it isn't. So, no
>XForms
> >processor would be obligated to process it, or adjust context nodes for
> >inner XPath expressions, etc.
> >
> >As long as the processor for the http://www.jbrix.org/ApplicationSchema
>took
> >care of all the app:prefixed markup, the below could probably be made to
> >work, though not in an interoperable way.
>
>It does take care of it, and it is all working.  I do in fact have
>functioning xforms - it's a matter of making them w3c xforms compliant.  My
>struggle is figuring out what that means!  :)  (Thank you for being patient
>with me, by the way.)
>
>But, unless I'm missing something, my app:application containing framework
>is no more un-compliant than an xhtml doc with multiple interlinked pages,
>built in whatever way the designer decides, and with whatever resources are
>at their disposal, that are interspersed with controls.  Is this a true
>statement?  I guess it gets back to my original question, which was what
>other contexts other than variously sized browsers are being considered..
>
>Thanks,
>Jim
>
>
>
> >Whether or not the conformance section of XForms would permit, deny, or
> >remain silent on the below sample hasn't been decided yet.
> >
> >Thanks,
> >
> >.micah
> >
> >
> >-----Original Message-----
> >From: Jim Wissner [mailto:jim@jbrix.org]
> >Sent: Monday, November 05, 2001 11:46 AM
> >To: www-forms@w3.org
> >Subject: Control heirarchies
> >
> >
> >
> >Hi,
> >
> >Let me try a different question.  It's short, I promise.  I need input if
> >possible.  A short "yes or no" to "is it valid?" is ok if that is all I
> >receive.
> >
> >Xforms doesn't seem to impose a specific control layout anymore.  So, for
> >instance, in an xhtml document you can have controls wherever, and the
> >model in the head section.  For non-xhtml container docs, could i
> >legitimately have a table that enumerates a nodeset, and then can be
> >"zoomed in" on to show more controls?
> >
> >Example:
> >
> >
> ><app:application
> >      xmlns:xforms="http://www.w3.org/2001/08/xforms"
> >      xmlns:app="http://www.jbrix.org/ApplicationSchema">
> >
> >      <xforms:model>
> >          <xforms:instance> . . . </xforms:instance>
> >          <xforms:bind ref="addressBook/person/firstName" required="true"/>
> >          <xforms:bind ref="addressBook/person/lastName" required="true"/>
> >      </xforms:model>
> >
> >      <xforms:input ref="@name">
> >          <xforms:caption>Address Book Name:</xforms:caption>
> >      </xforms:input>
> >      <app:table ref="addressBook/person">
> >          <app:caption>People</app:caption>
> >          <app:column name="Name" ref="{lastName}, {firstName}"/>
> >          <app:zoomed-view>
> >              <xforms:input ref="firstName" accessKey="f">
> >                  <xforms:caption>First Name:</xforms:caption>
> >              </xforms:input>
> >              <xforms:input ref="lastName" accessKey="l">
> >                  <xforms:caption>Last Name:</xforms:caption>
> >              </xforms:input>
> >          </app:zoomed-view>
> >      </app:table>
> >
> ></app:application>
> >
> >Does any of this invalidate xforms conformance?  And if it doesn't, which
> >from the spec I don't see why it would, then how can such documents be
> >compatible between "xforms compliant clients"?  What am I missing?
> >
> >I'm trying to keep my questions short, but I don't know how else to find
> >the answers, and users of my software are requesting conformance, so any
> >help with this would be fantastic.
> >
> >Thanks,
> >Jim

Received on Monday, 5 November 2001 19:58:45 UTC