W3C home > Mailing lists > Public > www-forms@w3.org > July 2005

RE: Using and extending XForms-Schema.xsd

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Thu, 21 Jul 2005 23:50:59 +0100
Message-ID: <0A324F30-A7DF-488C-95C6-B86ECC461C2F@S009>
To: "'Adrian Baker'" <adrian.r.baker@gmail.com>
Cc: <www-forms@w3.org>

Hi Adrian,

> Thanks for the link: that document addresses exactly the 
> schema mixing/extending problems I'm having, so I'm glad that 
> some thought is being put into this.

That's because there's a lot going on in this space! A lot of people need
the same functionality, and in particular there's quite some interest in
mixing XForms, SVG, MathML and so on.


> Regarding the use of QNames in the appearance tag, thanks for the tip
> - I can see that this can go a fair way towards providing 
> custom appearance 'hints'. However, some of the layout tags 
> we've created involve complex content specifying column 
> numbers, widths, section styles etc, which suits itself to a 
> metadata style element rather than an appearance. (Although 
> by the time the form is handed to the XForms engine it may be 
> encoded differently - this is more an abstract definition for 
> editing & storage).

I understand. You also might want to look at using xf:extension, which is
designed to allow you to place mark-up inside XForms elements.


> Also, we're using the Eclipse EMF & EMF.Edit frameworks to 
> generate a Java API to act as a basis for an editor/designer 
> (a web based one, interestingly enough). So the tighter and 
> more explicit we can make the schema, with our own element 
> types declared explicitly, the more useful and safe this API becomes.

The XForms schemas that I am building on in the work that I gave you the
link to, actually come from the Eclipse guys. They are nice and modular.
I've also had some discussion around requirements with the developers at
XFormation. Basically, schema-driven editing is a pretty trendy issue ;) and
the editor-builders really want this to work well.


> Anyway, for now I can achieve what I need to by editing the 
> XForms-Schema.xsd, but I certainly look forward to any 
> new/revised XForms schemas that make this avoidable :)

Indeed. They key thing is actually the modularisation of schemas. The
architecture you see in the link I sent is based almost entirely on the
model developed for XHTML 1.1 Modularisation, with just a couple of tweaks
to allow recursive nesting of languages. The idea is that you just add more
modules as you like, rather than editing schemas as you are being forced to
do now.

By the way, the work that I am doing on this is going to be fed back into
the XHTML 1.1 Modularisation work, as well as eventually into the XHTML 2 +
XForms 1.1 schemas. So if you want to post any of your use cases, to this
list or onto the wiki page that you looked at, (or to me personally if you
don't want them to be public) it would help, since it gives us one more test
to ensure that our model is 'working'.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/
Received on Thursday, 21 July 2005 22:51:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:01 GMT