insert, delete, and homogeneous sequences (a question, an answer)

[C. M. Sperberg-McQueen-2]

Another question, and another answer (by permission) from John
Boyer.

 > Q2.  I'm interested in XForms in part because they seem a
 > promising way of creating 'padded-cell' editors: specialized
 > XML editors designed for performing highly specialized tasks,
 > in such a way that (a) the person who must perform the task
 > need not learn a full XML editor, and (b) if they make a
 > mistake, the damage they can do is limited.  Example: an
 > interface to examine elements tagged by an automated process as
 > names, and to allow the user to mark them as names of people,
 > places, organizations, other, or not-a-name after all.

 > I'm trying to reach a clear understanding of how best to use
 > XForms for such editors, working on the assumption that like
 > most technologies XForms will work better on some kinds of XML
 > than on others.  So I'm thinking about the general create /
 > retrieve / update / delete operations, and wondering: what
 > things does XForms find easy to create, and what things can it
 > not create easily or at all?  What kinds of update are easy,
 > and what kinds are hard?  Ditto deletions.

 > So I have a general question, and a specific one.  General: s
 > there already somewhere a written characterization of the kinds
 > of XML that work best with XForms and the kinds that don't work
 > well?  Specific: xf:repeat handles only contiguous non-empty
 > sequences of sibling elements in the model, and xf:insert
 > inserts new elements only into such sequences.  A quick glance
 > at the table of contents of the spec doesn't show me any other
 > actions for adding new elements.  So am I right to suspect that
 > in general, XML vocabularies with content models of the form

 >   <!ELEMENT x (a | b | c)* >
 >   <!ELEMENT a EMPTY >
 >   <!ELEMENT b EMPTY >
 >   <!ELEMENT c EMPTY >

 > will be harder to deal with simply, while

 >   <!ELEMENT x (x-child)+ >
 >   <!ELEMENT x-child EMPTY >
 >   <!ATTLIST x-child
 >             type (a | b | c | dummy) 'dummy'
 >   >

 > will be easier, since the children of x will form a homogeneous
 > sequence?

John's reply:

 > Your second question has a shorter answer.  XForms 1.1 has
 > substantially revised the repeat element [1] as well as the
 > insert and delete actions [2] in order to eliminate the issue
 > of homogeneous collection and pretty much any other limitations
 > on XML processing.  The repeat element can use wildcards,
 > unions and any other XPath 1.0 mechanism to collect a set of
 > nodes over which the repeat operates.  The insert and delete
 > actions can reference and insert/delete elements, attributes,
 > text nodes, PIs, and comments.  I would imagine that some
 > implementers may have paid less attention to PIs and comments,
 > but failures should be reported as bugs since the spec calls
 > for it to be supported.  The only real limitation I can think
 > of is that XForms views XML through the lense of the XPath data
 > model.  So, for example, consecutive text nodes are out and
 > manipulating the DTD is not going to happen.  Otherwise, we
 > don't let you mess with namespace nodes (some implementers want
 > to experiment with that before we say how XForms will let that
 > happen, if at all).

 > [1] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#intro-diffs-ui
 > [2] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#intro-diffs-actions

[[In the light of this news, I discover I will be more eager than
I might otherwise have expected, to see 1.1 support in the
various XForms engines.  I'm glad to see people are working on
it.]]


--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

[Alain COUTHURES]

Hello,

While testing EMC Formula XForms engine, I have discovered this in the specs :

Thus, one might wish to use element repeat within a table to create the rows of a table, where each row of the table binds to a distinct member of a repeat collection. Since html:table doesn't  (and perhaps  never will) allow xforms:repeat elements as children, another syntax is needed.

It appears that it is not a constraint for XSLTForms to use xforms:repeat under html:table so I would like to know if it is still considered as a real problem, if it's forbidden or not.

Thank you for your answers.

Best regards,

Alain Couthures
<agencexml>
http://www.agencexml.com/xsltforms

[Erik Bruchez]

Alain,

Very good question. In Orbeon Forms as well, and for author
convenience, we allow xforms:repeat and xforms:group around tr and td
within tables, even though it is not "allowed". That could be a
problem if a web browser was looking at that DOM directly, but in our
case and in yours, or any situation where some sort of transformation
takes place first, I do not think it is an actual problem.

Wondering what other people think about this.

-Erik

On Tue, Aug 4, 2009 at 5:20 AM, COUTHURES
Alain<alain.couthures@...> wrote:

> Hello,
>
> While testing EMC Formula XForms engine, I have discovered this in the specs
> :
>
> Thus, one might wish to use element repeat within a table to create the rows
> of a table, where each row of the table binds to a distinct member of a
> repeat collection. Since html:table doesn't  (and perhaps  never will) allow
> xforms:repeat elements as children, another syntax is needed.
>
> It appears that it is not a constraint for XSLTForms to use xforms:repeat
> under html:table so I would like to know if it is still considered as a real
> problem, if it's forbidden or not.
>
> Thank you for your answers.
>
> Best regards,
>
> Alain Couthures
> <agencexml>
> http://www.agencexml.com/xsltforms
>

[Charles F Wiecha]

Sounds reasonable...my thinking this morning when originally reading the question what that it's sort of analogous to any other server-side "templating" approach, e.g. a mixture of HTML and JSP. One doesn't worry about whether that document is well-formed HTML since it doesn't have that purpose but rather is a generator of (hopefully) well-formed HTML for the client to consume...Charlie


Erik Bruchez ---08/04/2009 12:38:31 PM---Alain, Very good question. In Orbeon Forms as well, and for author

From:	Erik Bruchez <ebruchez@...>
To:	www-forms@...
Date:	08/04/2009 12:38 PM
Subject:	Re: Repeat within HTML table
Sent by:	www-forms-request@...

---

Alain,

Very good question. In Orbeon Forms as well, and for author
convenience, we allow xforms:repeat and xforms:group around tr and td
within tables, even though it is not "allowed". That could be a
problem if a web browser was looking at that DOM directly, but in our
case and in yours, or any situation where some sort of transformation
takes place first, I do not think it is an actual problem.

Wondering what other people think about this.

-Erik

On Tue, Aug 4, 2009 at 5:20 AM, COUTHURES
Alain<alain.couthures@...> wrote:
> Hello,
>
> While testing EMC Formula XForms engine, I have discovered this in the specs
> :
>
> Thus, one might wish to use element repeat within a table to create the rows
> of a table, where each row of the table binds to a distinct member of a
> repeat collection. Since html:table doesn't  (and perhaps  never will) allow
> xforms:repeat elements as children, another syntax is needed.
>
> It appears that it is not a constraint for XSLTForms to use xforms:repeat
> under html:table so I would like to know if it is still considered as a real
> problem, if it's forbidden or not.
>
> Thank you for your answers.
>
> Best regards,
>
> Alain Couthures
> <agencexml>
> http://www.agencexml.com/xsltforms
>

[Ulrich Nicolas Lissé-3]

Alain,

that's what the xf:repeat-* attributes are for. They have been  
introduced with XHTML tables in mind. However, they are not normative.  
See http://www.w3.org/TR/xforms11/#ui.repeat.via.attrs for reference.

Regards,
Uli.

On 04.08.2009, at 14:20, COUTHURES Alain wrote:

> Hello,
>
> While testing EMC Formula XForms engine, I have discovered this in  
> the specs :
>
> Thus, one might wish to use element |repeat| within a |table| to  
> create the rows of a table, where each row of the table binds to a  
> distinct member of a repeat collection <http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html#defn-repeat-collection 
> >. Since |html:table| doesn't  (and perhaps  never will) allow |
> xforms:repeat| elements as children, another syntax is needed.
>
> It appears that it is not a constraint for XSLTForms to use  
> xforms:repeat under html:table so I would like to know if it is  
> still considered as a real problem, if it's forbidden or not.
>
> Thank you for your answers.
>
> Best regards,
>
> Alain Couthures
> <agencexml>
> http://www.agencexml.com/xsltforms

--
Ulrich Nicolas Lissé

[Scott Shattuck]

On Aug 4, 2009, at 10:40 AM, Charles F Wiecha wrote:

> Sounds reasonable...my thinking this morning when originally reading  
> the question what that it's sort of analogous to any other server-
> side "templating" approach, e.g. a mixture of HTML and JSP. One  
> doesn't worry about whether that document is well-formed HTML since  
> it doesn't have that purpose but rather is a generator of  
> (hopefully) well-formed HTML for the client to consume...Charlie
>
>

For clarity, I think you _do_ care about well-formed XML, but don't  
care whether it will validate against a particular XHTML schema/DTD.

ss


Scott Shattuck
Team TIBET(tm)