Return-Path: Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 58424 invoked from network); 10 May 2000 17:13:23 -0000 Received: from benjamin.webslingerz.com (206.66.49.217) by locus.apache.org with SMTP; 10 May 2000 17:13:23 -0000 Received: from phoenix.webslingerZ.com (phoenix.webslingerZ.com [206.66.49.24]) by benjamin.webslingerZ.com (Postfix) with ESMTP id C3562C0AB for ; Wed, 10 May 2000 13:16:05 -0400 (EDT) Received: from localhost (balld@localhost) by phoenix.webslingerZ.com (8.8.7/8.8.7) with ESMTP id NAA13685 for ; Wed, 10 May 2000 13:12:54 -0400 X-Authentication-Warning: phoenix.webslingerZ.com: balld owned process doing -bs Date: Wed, 10 May 2000 13:12:54 -0400 (EDT) From: Donald Ball To: cocoon-users@xml.apache.org Subject: Re: Anyone using XMLForm? In-Reply-To: <3919121C.98EB19E@denic.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Wed, 10 May 2000, Ulrich Mayring wrote: > svenk@Informatik.Uni-Bremen.DE wrote: > > > > Same for me. Indeed, this html type is almost doing too much. I don't > > want those tags to be converted to upper case (because that's no xhtml); > > also I don't want those HTML-Entities, now that I have proper encoding > > ;-) > > Guess I'll have to go trough the openxml stuff to fix this. > > Why not just make it type xml or no type at all? Didn't try XML, but no > type at all preserves the Umlaute and doesn't convert them to entities. > > > Yet another issue: How do I make it encode the attributes of the element > > as POST parameter as well? I tried something like > > @*|/name[title={blabla}] as xmlform:xpath but did not succeed. Is my > > xpath false or does XMLForm not support attributes yet? > > You seem to run into the exact same problems as I :-) > > Another thing is this: > > > foobar > baz > > > Here you will get only ONE parameter /news/item and it will have the > value foobar. The second and all following items are ignored. It is not > possible to tell the items apart by their id attribute, because XMLForm > doesn't post the attribute values. Now you're poking holes at the underlying premise of XMLForm. It's not very easy to construct an arbitrary tree from a collection of XPath-like expressions. Maybe you and Jeremy should get together to work on the next iteration of this concept - he had the good thought of generating the form from a skeletal XML fragment so that it would be easier to map form elements to XML result nodes. If y'all want to take over maintenance of XMLForm, let me know. - donald