- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Mon, 3 Aug 2009 18:54:05 -0600
- To: www-forms@w3.org
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
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 ****************************************************************
Received on Tuesday, 4 August 2009 00:54:45 UTC