RE: [ubl-dev] Simpler-Than-UBL Design Rules

["David RR Webber \(XML\)" <david@drrw.info>]

Steve,

Yes - I feel a little awkward here - on the AJAX front - but anyway -
just some quick points (I do think you need to take a second look at
AJAX - there's some WAY cool stuff - hint see Google's tools...)- 

- AJAX is very much a client-side technology - the server part is as
much or little as you desire.
- You can use AJAX entirely locally - no server - if you desire.
- AJAX is all about XML IMHO!
- it avoids script - because the JS is just an include - those library
routines then read the XML config - and direct the form controls -
event model
- so scripting is easy - can be all at xml level - and of course - tools
write it for you...
- There is really very little difference conceptually between XForms and
AJAX - just deployment model details
- Only Web browser?  Not sure - I'd wager someone has a standalone none
browser deployment!

Anyway - if we can do both - then it plays to both pools of
opportunity...

Cheers, DW

"The way to be is to do" - Confucius (551-472 B.C.)
 

 -------- Original Message --------
Subject: RE: [ubl-dev] Simpler-Than-UBL Design Rules
From: stephen.green@systml.co.uk
Date: Wed, February 07, 2007 12:30 pm
To: ubl-dev@lists.oasis-open.org

Many thanks David for very useful comments (a good reference
for considering XForms vs AJAX I think).

But does AJAX enable schema/model-driven (CASE-like) * client *
validation? I gathered AJAX was almost all about server-side.
That's my main motivator - to allow client side, schema/model-
driven generation with all bells and whistles, relying almost
nill on what is on a server. That seems appropriate for B2B
where one doesn't know what is on a server particularly and
doesn't want to have to pay someone to change it when modifying
the schema (schema in a loose sense, not necessarily just XSD
though XForms seems to rely on XSD for its client validation).
So AJAX is about servers (can be downside) and also about
script of course. Not sure why you say it can avoid script :-)
Of course I realise there are tools to generate the script but
don't they still put script into the browser? So script means
obfuscation (especially with AJAX, I think - very obscure script)
and reliance on browsers (not so XForms) and lots of high-skilled
developers (and lots of development time I think, even with tools
since I take it the code still needs debugging and maintaining).
That's my own assessment anyway.

Interesting discussion but I guess I should keep to UBL
since this is UBL-dev not xml-dev :-)

All the best

Steve



Quoting "David RR Webber \(XML\)" <david@drrw.info>:

> Steve,
>
> On Xpaths - yes - of course you can use the full XPath - just check the
> checkbox on the entry control  (Martin also has this all demo'd in the
> new tutorial part 2 from the website).
>
> The other aspects you mention - codelists, and use of XPath to control
> when certain validations apply - yes CAM does this - you can see this
> at work in the order and invoice templates where the Xpath /* child
> referencing causes one CAM function to reference content whereever it
> is in the template...and then you can do specific overrides to exact
> XPaths.
>
> Good to know your rationale behind XForms (was wondering about that).
> The better AJAX implementations are using XML control file(s) to
> configure the form and controls and validations.  Autogenerating that
> control XML is the identical method to XForms using the xsd... some
> more comments inline below.
>
> Cheers, DW
>
>
> "The way to be is to do" - Confucius (551-472 B.C.)
>
>
>  -------- Original Message --------
>
> I've thought a bit about using AJAX but that would
> seem to be a backward step:
>>> (yikes!  the industry is betting on AJAX - and I
>  personally love it because of its open layered model!)
>
> firstly, no advantage I'd have thought on the client
> side as there is no assertion that the client forms
> processor (browser only I should think with AJAX) has
> a built-in means of validating against any kind of schema
>>> some AJAX tools allow xsd to be used to create default
>    validations - but yes - then AJAX has ability to load
>    from an XML control file the validation rules
>
> secondly, no built-in facilities for avoidance of script,
> declarative programming, framework for good practise,
> or nice way of doing repeats
>>> ??? Yikes! I do believe AJAX does all of this!
>
> thirdly, the requirements of customisation and context
> are such that it seems preferable to use schema-driven
> code generation to allow changes to schemas (or models
> if you prefer) to be rippled in a CASE-like way into
> the form - not sure you can reliably do this with AJAX
> as it seems you can with XForms.
>>> If the CASE tool is re-generating the XML control
>    files that the AJAX loads - then I believe "Yes"
>    it can support this.
>
> fourthly, I've come across converters from XForms to
> AJAX but not the other way so I'd prefer to start with
> the XForms which * can * it seems be schema-driven and
> optionally generate the AJAX or whatever - which might
> answer some of the above to some extent (yet to look
> into that thoroughly though)
>
>>> I'm thinking that a generic CAM-based "generate"
>    method should work for both - since the principles
>    are identical - just the XML-syntax used is the
>    varient - e.g. "dialects" - while the xhtml is a
>    common rendering...
>
> We will have to experiment with all this over the next
> few weeks.  I agree your XForms samples provide a nice
> initial set of target samples to replicate...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org