W3C home > Mailing lists > Public > www-forms@w3.org > August 2009

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

From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
Date: Mon, 3 Aug 2009 18:54:05 -0600
Message-Id: <57BE742D-7A21-4D24-A23C-EA8398CB5AB5@blackmesatech.com>
To: www-forms@w3.org
Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
Another question, and another answer (by permission) from John

 > 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

* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
Received on Tuesday, 4 August 2009 00:54:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:22 UTC