RE: [xml-dev] Serialising XML Schema to HTML form and getting itback as

[Philip Fennell <Philip.Fennell@marklogic.com>]

Lech,

> I am thinking that XRX would simplify the process greatly 

Yes, I'd agree with you.

> and simply eliminate the need for things like a db schema 

That is at odds with your original requirement for validation of input. You need to define your constraints in some form or other. If you are going to use schemas (XSD, RelaxNG, Schematron, etc) then you need to put them at the heart of your process. If you don't then they, and the content, will get out-of-sync real quick.

> What does MarkLogic or other XML Application offer on the backend side?

From the content point of view, things like validation on create/update, application servicers (delivering the forms), content processing frameworks. Now that MarkLogic 4.2 has been released you'll have XSLT 2 at your disposal for generating the XForms from your schema(s).

> How would you do it so that features like restful CRUD and
> Search are done automatically rather than coded?

As for code generation, if you were to describe your RESTful Web Service using the Web Application Description Language (WADL)

<https://wadl.dev.java.net/wadl20090202.pdf>

It is entirely possible to generate other parts of your client-side XForms application and the server-side XQuery stubs that will submit/respond respectively the requests the client-side application makes.

I have done some work, not complete so nothing I can pass on other than advice, and it is potentially a viable solution. Also you can generate documentation too by transforming your WADL service description into XHTML etc, etc.

And, as with the schemas, if your going to use WADL then you need to also put them at the heart of your process too.

Code generation tends to be fussy about the input-source so you'll need to agree on schema design patterns etc and then ensure people adhere to them by having schema tests as part of your Continuous Integration environment. Or, if you don't have that then some needs to make sure it happens manually!


Regard

Philip Fennell 
Consultant

MarkLogic Corporation
Mobile +44 (0) 7824 830 866
email  Philip.Fennell@marklogic.com
web    www.marklogic.com

This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.

________________________________________
From: Lech Rzedzicki [xchaotic@gmail.com]
Sent: 14 October 2010 14:09
To: xml-dev@lists.xml.org
Cc: Philip Fennell
Subject: Re: [xml-dev] Serialising XML Schema to HTML form and getting it back as XML instance

Philip, thanks again for the reply.

I think the idea has been received here with a lot of enthusiasm, with
one important caveat:
A more traditional approach with a more relational persistence layer,
could yield us a lot more in terms of code generation.
For instance, using Java frameworks, we could generate db schema,
appropriate code for classes and objects, class diagrams,
documentation, easy load balancing/deployment to the cloud..

I am thinking that XRX would simplify the process greatly and simply
eliminate the need for things like a db schema - you'd simply store
XML instances as such, but there's still need to produce the glue
code.
What does MarkLogic or other XML Application offer on the backend
side? How would you do it so that features like restful CRUD and
Search are done automatically rather than coded?

Lech

On 11 October 2010 13:35, Philip Fennell <Philip.Fennell@marklogic.com> wrote:

> If you chose, for example, XSLTForms <http://www.agencexml.com/xsltforms> then you would not be 'sending HTML + JS over the wire' as XSLTForms uses client-side XSLT to transform the sent XForms into XHTML+JavaScript. XSLTForms is very easy to deply as it is, in effect, a set of static files whilst the server-side implementations require some form of application server although both solutions are effectively transparent to the user and the form developer only works with XForms, and ultimately that's what XForms is all about.