RE: SVG ouside the browser...

Jim,

> > The data that comes back is then checked and if there is no error 
> > code, and the data is XML, it is placed in an instance (or could be 
> > used as a new page).
> 
> Where it needs to be checked all again of course, so we've 
> not simplified 
> things ...

This is a common argument, but with respect, it's completely upside down! We
are *already* validating on the server, right? We already check our data
before it goes into our databases, before we contact the credit-card
company, before we reserve the seat, order the book, mark the bug as fixed.
That's not going to change, and we all know that it can't. But at the
moment, if we want to improve the user experience by saving a round-trip to
the server, we would need to do some of the checks on the client (which will
also save some bandwidth and server load into the bargain).

So what do we do? Well today, we need to code up some script to do that
checking. But the stupid thing is that we probably already have the 'logic'
of many of the validations we need to perform, in the form of a schema on
the server. We might have a schema that says an email address is as follows:

<xsd:simpleType name="email">
  <xsd:restriction base="xsd:string">
    <xsd:pattern
 
value="[A-Za-z0-9!#-'\*\+\-/=\?\^_`\{-~]+(\.[A-Za-z0-9!#-'\*\+\-/=\?\^_`\{-~
]+)*@[A-Za-z0-9!#-'\*\+\-/=\?\^_`\{-~]+(\.[A-Za-z0-9!#-'\*\+\-/=\?\^_`\{-~]+
)*"
    />
  </xsd:restriction>
</xsd:simpleType>

but unfortunately we can't use it, since our client software doesn't
understand schemas. Of course a seasoned scripter could easily code this up,
since it is just a regular expression, but now you have to maintain the
logic in two places -- in the XML schema, and in the script. But the script
is part of the 'user interface', not the data, so what's it doing encoding
business logic? That's not exactly leading-edge software development
principles ;).

XForms *does* understand schemas -- in fact XML standards like XPath, XML
Events and XML Schemas are built into the heart of XForms. And there are
plans to introduce other schema types, like RELAX NG, and even Schematron.
In this model all we need to do is refer to the schema from our form, and if
the 'back-end' programmers change the data type, or fix a problem with the
schema definition, we don't need to go and find all the places where the
script was used.


> ... one of the things we do to simplify script is do very simple 
> validation to pick up the 90% of silly answers (e.g. we might 
> check that 
> there's something in the date field ...

Most web-sites I've seen use incredibly clever scripts and DHTML, but
ultimately all they do is allow dates to be entered in English, usually
using US date formats. (And it's worth saying in passing that these
client-side validations scripts are often wrong anyway -- the tests for
email addresses for example often only allow for the most common forms.)
XForms on the other hand separates out 'date entry' into the underlying data
and an abstract widget. The widget should be localised for the user --
Chinese, French, etc. -- but the value should be stored in a standard way.


> ... but we won't check that 
> they're not 
> trying to buy a train ticket for last week [*])  This 
> simplifies the script, 
> and reduces the amount of duplication - sure we can do the 
> simple checks in 
> the X-Forms instances too, but are we really then using the X-Forms 
> strengths?

XForms can do both though. And the key point is that it does it
declaratively -- one of its strengths. Of course you may *convert* the
following to a script at some point, and some XForms implementations do, but
it's surely easier to write the following bind statements, than the
corresponding script:

  <xf:instance>
    <data xmlns="">
      <startdate />
      <enddate />
    </data>
  </xf:instance>

  <xf:bind nodeset="startdate" type="xsd:date" />
  <xf:bind
   nodeset="enddate"
   type="xsd:date"
   constraint=". &gt; ../startdate"
  />

The @type attribute says that the two nodes are dates, and the @constraint
attribute says that the end date must be greater than the start date (your
example could be coded as constraint=". &gt; now()").

Now, any time that the end date does not satisfy its two conditions (of
being both a date, and greater than the start date), any control that uses
that node will receive an event saying that data is invalid (and you'll get
another event when it becomes valid again). You'll also get CSS
pseudo-classes of ::invalid and ::valid automatically applied.

So, if we use the data in a control:

  <xf:input ref="enddate">
    <xf:label>End date:</xf:label>
    <xf:alert>The end date must be ...</xf:alert>
  </xf:input>

now if we want it to have a red background on the control when the error
condition applies, we just do this:

  ::invalid { background-color: red; }

And if we want the <alert> to be hidden when the control is valid, but shown
in red when invalid, we do this:

  ::invalid > xf|alert { color: red; }
  ::valid > xf|alert { display: none; }

And this is where I would suggest it becomes really relevant to the SVG
world -- if you coded up a lovely 3D date-picker and wired it into XForms
you would receive the events for valid and invalid, and the CSS styles
::invalid and ::valid. All you then need to do is code up the widget, and
leave the validation and so on to the XForms engine. (Note that the schema
type of date is all that is needed to say that the input control should be a
date-picker.) You are now in the enviable position of allowing the data and
the UI to be developed separately, and to move independently of each other.
It's a bit like programming to a standard API but far more flexible, since
in the main the interfaces are events.

It doesn't take much to extend this idea to include a map that allows a city
to be selected, a thermometer that renders a temperature, a digital clock,
an analogue clock, even a compound of carbon, hydrogen and oxygen atoms.
(And of course widgets can be audible, such as a speaking clock.)


> > Now, a customer of ours wanted to be able to access an Oracle Lite
> > database
> > on their users' laptops, so that they could work offline.
> 
> This is much more where I see the utility of X-Forms, not in the 
> web-application arena, but in the local lightweight 
> application arena, that 
> re-uses web and web-like technology for rapid application deployment, 
> especially of systems that have had an online analog (so 
> local product 
> databases, or offline bug/user trackers etc.)

I of course agree with you there, but I suppose the difference between us is
that I see these two worlds converging more and more. When you look at an
online application like Salesforce.com, you realise that the functionality
people want when they are 'online' is pretty much what they would expect
from a 'traditional' application. But when you also see that Gmail recently
provided POP3 access, you realise that despite the loud claims to the
contrary, current UI technologies really can't give users the same
experience that an Outlook or Eudora does.

Now, an email client written with XForms and SVG, that could be re-skinned
just be changing the SVG widgets ... I'd use that all the time.


> My own development of these sort of things has always used Zeepe and 
> HTML/script, am I ready to move to a forms player, I dunno, 
> I've never 
> evaluated one sufficiently to know, so I'll carry with the 
> devil I know 
> until I get the time for that.  X-Forms haven't yet sounded 
> persuasive 
> enough to make the jump.  Not least because I have more faith 
> in the mature 
> trident never changing, than what are still young X-Forms 
> implementations.

Ah ... that's a different issue, and it's of course fair enough to be
cautious.


> That is where I see the utility of X-Forms, but the problem 
> here is, it's 
> quite a niche, and I don't know if it's worth learning the necessary 
> skills - (which is similar to the question if learning the 
> skills of SVG is 
> valuable as well)  I really like the concept of X-Forms, it's 
> just I don't 
> know if it's enough of an improvement for me to invest in the 
> new set of 
> problems I'm going to have to solve.

Sure, and it's my job to persuade you otherwise (continuing this Friday at
the SVG Users Group meeting in London, where I look forward to seeing you).

So, once again, thanks for taking the time to engage with the issues, and
giving me the opportunity to sound off for a bit.

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/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Thursday, 25 November 2004 00:33:11 UTC