Re: Fw: XForms 1.2 Design Principles, Forms Architecture

Hi Mark,

I completely agree that our syntax in XForms 1.1 is bit to verbose. And 
the efforts we are doing to create a more compact syntax is really great 
and I'm a 100% supporter.

But if an HTML author writes a form:

  <form action="search-by-name.php" method="get">
    <input name="fn" onchange="output.innerHTML=fn.value + ' ' + sn.value" 
/>
    <input name="sn" onchange="output.innerHTML=fn.value + ' ' + sn.value" 
/>
    <span id="output"></span>
 
    <button name="submit" type="button" onclick="verifyAndSubmit()"
>Submit</button>
  </form>

That converted to XForms becomes:

  <input name="fn" />
  <input name="sn" required="true()" />
  <output value="concat($fn, ' ', $sn)" />

  <submit resource="search-by-name.php" 
method="get"><label>Submit</label></submit>

It is hard for me to accept that a form author is willing to convert his 
javascript to XPath and move those expressions to other elements in the 
document for calculates and validation. And is not willing to move the 
submit related attributes to the submit element (if he wants he can still 
use the action attribute, it is deprecated but still works).


Note: I know that the label child is missing for the input elements. 
Personally I would be happy to re-introduce the label 'for' construct 
again to XForms, I know that it maybe can have drawbacks for accessibility 
but if they are linked by id's I personally I don't see the difference in 
putting it as a child or linking it through an ID. And requiring it being  
a child would make live easier for me in a lot of forms.

Regards,

Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com

"Mark Birbeck" <mark.birbeck@x-port.net> wrote on 04/16/2008 11:12:11 AM:

> Hi Nick,
> 
> I think some of the design principles behind the proposed changes are
> being lost in this discussion.
> 
> The original proposal was that we provide an XForms interpretation of
> an HTML form. That is not quite the same as saying that HTML form
> elements are now part of XForms, although of course we will need to
> document the whole thing somewhere. It is simply about providing
> authors with somewere to go when they want to add functionality to
> their forms.
> 
> Say an author starts with this simple HTML form:
> 
>   <form action="search-by-name.php" method="get">
>     <input name="fn" />
>     <input name="sn" />
>   </form>
> 
> where can they go next, if they want to improve this form?
> 
> Let's say they want to show the full name on the form after a user has
> typed it in. Using XForms that's easy:
> 
>   <xf:output value=(concat(../fn, ' ', ../sn)" />
> 
> But how does our HTML author get access to that simple formulation? At
> the moment, with no XForms simplification, they have to leap straight
> into the full power of XForms:
> 
>   <xf:model>
>     <xf:instance>
>       <instanceData xmlns="">
>         <fn />
>         <sn />
>       </instanceData>
>     </xf:instance>
> 
>     <xf:submission action="search-by-name.php" method="get" 
> separator="&amp;" />
>   </xf:model>
> 
>   <xf:input ref="fn">
>     <xf:label>First name</xf:label>
>   </xf:input>
> 
>   <xf:input ref="sn">
>     <xf:label>Surname</xf:label>
>   </xf:input>
> 
>   <xf:output value=(concat(../fn, ' ', ../sn)" />
> 
> So just to get a form with two strings concatenated, our author has
> had to learn XForms, including XPath and XML. Not only is this
> unnecessary, but it prevents people from using XForms, since the curve
> is so steep. And the real irony is that the data that will be sent to
> the server in these two examples will be exactly the same!
> 
>   search-by-name.php?fn=abc&sn=xyz
> 
> What we end up with is a different answer to the question 'where do
> they go next'; the answer is that they move to JavaScript to
> concatenate their two strings and get the extra functionality that
> they need:
> 
>   <form action="search-by-name.php" method="get">
>     <input name="fn" onchange="output.innerHTML=fn.value + ' ' + 
sn.value" />
>     <input name="sn" onchange="output.innerHTML=fn.value + ' ' + 
sn.value" />
>     <span id="output"></span>
>   </form>
> 
> It's horrible, because we're now dealing with the DOM, script, event
> handlers and so on. But it's still a lot quicker to do this than to
> learn XForms! :)
> 
> 
> TWO-PRONGED APPROACH
> 
> So, my argument when I first proposed that we tackle this problem was
> that we should attack it from two sides. The first side involves
> simplifyiing XForms itself. We already have lazy authoring, which
> would allow our author to remove the instance:
> 
>   <xf:model>
>     <xf:submission action="search-by-name.php" method="get" 
> separator="&amp;" />
>   </xf:model>
> 
>   <xf:input ref="fn">
>     <xf:label>First name</xf:label>
>   </xf:input>
> 
>   <xf:input ref="sn">
>     <xf:label>Surname</xf:label>
>   </xf:input>
> 
>   <xf:output value=(concat(../fn, ' ', ../sn)" />
> 
> But I proposed also that we get more flexible about the model element,
> allowing it to be removed altogether, and allowing other elements
> (like submission and bind) to exist outside of the model element. Our
> author could now do this:
> 
>   <xf:submission action="search-by-name.php" method="get" 
separator="&amp;" />
> 
>   <xf:input ref="fn">
>     <xf:label>First name</xf:label>
>   </xf:input>
> 
>   <xf:input ref="sn">
>     <xf:label>Surname</xf:label>
>   </xf:input>
> 
>   <xf:output value=(concat(../fn, ' ', ../sn)" />
> 
> Our form is starting to look a little less scary for a new author, and
> not a million miles from its HTML equivalent.
> 
> Which brings us to the second line of attack; to allow an HTML form to
> actually be a fully-fledged XForm. That means interpreting HTML forms
> as if they had been designed using an MVC architecture. One way to do
> that is to say that the HTML form element creates a model, a default
> instance, and a submission, and further, that each control creates a
> node in the default instance (lazy authoring) as well as a bind
> statement that connects to that node. Which means that although this
> is good old-fashioned HTML:
> 
>   <form action="search-by-name.php" method="get">
>     <input name="fn" />
>     <input name="sn" />
>   </form>
> 
> It is also 'XForms'. Not necessarily XForms in the mark-up language
> sense, but definitely XForms in the processing model sense (think of
> it in the same way that XML now has an infoset that is distinct from
> the mark-up itself).
> 
> So to return to 'the next step' for our HTML author; recall that to
> get the first name and surname concatenated on their form, they had to
> make use of script and event handlers:
> 
>   <form action="search-by-name.php" method="get">
>     <input name="fn" onchange="output.innerHTML=fn.value + ' ' + 
sn.value" />
>     <input name="sn" onchange="output.innerHTML=fn.value + ' ' + 
sn.value" />
>     <span id="output"></span>
>   </form>
> 
> But in our world, where an HTML form is being processed by an XForms
> processor, we have a full dependency-engine sitting under the hood! We
> don't need to bother registering for the onchange event of every
> control, and then digging out the value of the control from the DOM,
> before setting another value, also via the DOM. All we have to do is
> this (keeping namespace prefixes so as to draw attention to the
> elements):
> 
>   <form action="search-by-name.php" method="get">
>     <input name="fn" />
>     <input name="sn" />
>     <xf:output value=(concat(../fn, ' ', ../sn)" />
>   </form>
> 
> And we can simplify this further. As you know, another part of my
> proposal was the use of named binds to save the author from having to
> get into XPath at this early stage, and on the table at the moment is
> the use of the dollar syntax to achieve that. So our form would
> become:
> 
>   <form action="search-by-name.php" method="get">
>     <input name="fn" />
>     <input name="sn" />
>     <xf:output value=(concat($fn, ' ', $sn)" />
>   </form>
> 
> So by recasting our HTML form as an XForm, at least in its
> architecture and processing life-cycle, we provide authors with the
> power to enhance their forms without scripting, and without having to
> make the leap to understanding all of XForms.
> 
> To illustrate, let's imagine that the author wants to insist that the
> user enters at least a surname? In our current XForms model the author
> would once again have to embrace all of XForms. In our current HTML
> model our author would once again have to dive down to script with
> event handlers, probably checking the values just before submitting
> the data. But in our new 'simplified XForms' model, the author simply
> adds a bind statement:
> 
>   <form action="search-by-name.php" method="get">
>     <xf:bind name="sn" required="true()" />
> 
>     <input name="fn" />
>     <input name="sn" />
>     <xf:output value=(concat($fn, ' ', $sn)" />
>   </form>
> 
> In other words, they keep adding more and more of the powerful
> features of XForms.
> 
> (We're also discussing having @required on UI controls, which would
> make this slightly simpler.)
> 
> I hope by the way, that this clarifies that we need to support *all*
> of the elements in HTML, not just some; by which I mean we need to
> provide an 'XForms interpretation' of all of HTML.
> 
> Regards,
> 
> Mark
> 
> 2008/4/16  <Nick_Van_den_Bleeken@inventivegroup.com>:
> >
> > Hi John,
> >
> > It seems that I am the only one that doesn't likes to have a language 
that
> > has different elements (with different attribute names) that do 
similar
> > things. I personally like to keep a 'programming' language so simple 
as
> > possible (no synonyms for language constructs for example). Because 
you now
> > require an author to know both syntaxes because he almost never works 
alone
> > on it and the other guy is likely to use the other construct that the 
first
> > one is used to. But I think I already stressed this opinion in my 
previous
> > e-mail(s) and I'm not going to repeat myself anymore. Everyone knows 
my
> > standpoint, and if the group wants to add the old html elements to the 
Core
> > XForms language, then I just need to get used to learn all those new
> > elements which enable you to do things we already can do with other
> > elements.
> >
> > A last thing I would like to say about this is that I feel that it is
> > against what we were saying in Raleigh, I think that the form, 
fieldset and
> > option elements are good candidates to put in a Module XForms for HTML 
Form
> > Authors (or in separate modules).
> >
> > Regards,
> >
> >  Nick Van den Bleeken  -  Research & Development Manager
> >  Inventive Designers
> >  Phone: +32 - 3 - 8210170
> >  Fax: +32 - 3 - 8210171
> >  Email: Nick_Van_den_Bleeken@inventivegroup.com
> >
> > public-forms-request@w3.org wrote on 04/16/2008 03:08:08 AM:
> >
> >
> >
> >  >
> >  > Hi Nick,
> >  >
> >  > The form tag is described as creating an *outer* model.  Any model
> >  > elements *within* it are described as creating inner models to the
> >  > outer model implied by the form tag!?!  This means having the form
> >  > tag around is useful because it is a convenient place to catch
> >  > events targeted at the implied model and implied submission.
> >  >
> >  > We would not necessarily expect to add fieldset, although it
> >  > wouldn't kill us.  At a minimum, HTML5 should be able to attach
> >  > their fieldset to XForms "as if it were an xforms:group" by using
> >  > the name attribute.
> >  >
> >  > Yes we are saying XPath is the expression language *for declarative
> >  > expressions*.  It is better that these NOT be javascript because we
> >  > don't want to give access to javascript in calculations because
> >  > javascript functions can access the DOM.  However, for lots of
> >  > expressions, how a web author writes them will be easy to
> >  > understand.  A plus sign is a plus sign.  Yes, I do expect there
> >  > will be violent opposition to this, but the reactions to our ideas
> >  > seem to be binary, so it's just something we have to live with and
> >  > work on.  They will not be able to make the rejection based on
> >  > unavailability of XPath in any real browser, so rejecting the idea
> >  > will ultimately come across as obstructionist.
> >  >
> >  > Finally, as for adding elements we left out on purpose, like
> >  > fieldset, I suppose I can't understand the rationale.  We have the
> >  > same element that does the same thing, only it is spelled
> >  > differently.  The HTML WG and before that WF2 are making the point
> >  > that these changes of spelling were made unnecessarily and they are
> >  > causing adoption problems for the web author community.  Why not
> >  > support the tag?  To wit, notice that select and select1 support
> >  > optgroup.  Why?
> >  >
> >  > If there is no compelling reason *not* to support a tag set from
> >  > HTML, then we have to eat our own dogfood here.  We want others to
> >  > use XForms because it has precedence as a W3C recommendation, so we
> >  > have to be willing to bend a bit and support the reasonable tag
> >  > names that set precedents for us.  Tags like fieldset, option,
> >  > optgroup and even label don't seem unreasonable.
> >  >
> >  > In fact, it is interesting to note that our table creation story 
via
> >  > repeat does leave a few things to be desired because we have 
nothing
> >  > more intelligent than repeat to bind together all the other things
> >  > needed to really make a table.  It seems to me that whatever we 
come
> >  > up with should borrow as much as possible from HTML table which, in
> >  > combination with xforms repeat, could be a very powerful tool.  I
> >  > would expect, for example, that at least HTML5 authors should be
> >  > able to use *our* repeat to iterate <tr> tags.
> >  >
> >  > Cheers,
> >  > John M. Boyer, Ph.D.
> >  > Senior Technical Staff Member
> >  > Lotus Forms Architect and Researcher
> >  > Chair, W3C Forms Working Group
> >  > Workplace, Portal and Collaboration Software
> >  > IBM Victoria Software Lab
> >  > E-Mail: boyerj@ca.ibm.com
> >  >
> >  > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> >
> >
> >  > Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/
> >  > JohnBoyer?flavor=rssdw
> >  >
> >  >
> >  >
> >
> > >
> >  > Nick_Van_den_Bleeken@inventivegroup.com
> >  > Sent by: public-forms-request@w3.org
> > > 04/15/2008 02:32 AM
> > >
> >  > To
> > >
> >  > XForms <public-forms@w3c.org>
> > >
> >  > cc
> > >
> >  > Subject
> > >
> >  > Fw: XForms 1.2 Design Principles, Forms Architecture
> > >
> >  >
> >  >
> >  >
> >  >
> >  > I noticed that I forgot to copy this e-mail to the list....
> >  >
> >  > Nick Van den Bleeken  -  Research & Development Manager
> >  > Inventive Designers
> >  > Phone: +32 - 3 - 8210170
> >  > Fax: +32 - 3 - 8210171
> >  > Email: Nick_Van_den_Bleeken@inventivegroup.com
> >  > ----- Forwarded by Nick Van den Bleeken/Inventive Group on 04/15/
> >  > 2008 11:30 AM -----
> > >
> >  > Nick Van den Bleeken/Inventive Group
> > > 04/11/2008 02:57 PM
> > >
> >  > To
> > >
> >  > John Boyer <boyerj@ca.ibm.com>
> > >
> >  > cc
> > >
> >  > Subject
> > >
> >  > Re: XForms 1.2 Design Principles, Forms ArchitectureLink
> > >
> >  >
> >
> > >
> >  >
> >  >
> >  >
> >  > Personally I think these guidelines are going o have little chance
> >  > of getting accepted by all the members of the Forms TF because, as 
I
> >  > read it XForms adopts the name attribute, the form element and
> >  > therefore HTML forms needs to have XPath as its expression 
language, and
> > ...
> >  >
> >  > The more I think about our current approach to import html-form
> >  > elements into XForms the more I get doubts about it :
> >  >
> >  > We are thinking (or have decided) to import the form element which
> >  > is conceptually an XForms model. This has some disadvantages :
> >  >  1. Event flowing : The form element is currently described as
> >  > creating an inner model in the default model. If you explicitly add
> >  > the default XForms model element the form element isn't a child
> >  > element of the model but I guess you want the event to capture/
> >  > bubble from the default model to the inner model. But this doesn't
> >  > work, because the form-element is not a child element from the
> >  > default model element.
> >  >  2. Single root: The advantage of XForms is that when you have two
> >  > forms on one page (i.e. two models) you can hierarchically
> >  > interchange the elements/controls from the two models
> >  >
> >  > In XForms we have the group element (with label), in HTML forms 
they
> >  > use fieldset (with legend) to group controls. Are we going to add
> >  > the fieldset element to group controls to Core XForms too?
> >  >
> >  > Don't understand me wrong, the addition of the name attribute 
(named
> >  > binds, other in-line evaluation context) is great, it adds real
> >  > functionality to the XForms language. But adding elements that were
> >  > left out on purpose because they were replaced by better constructs
> >  > is a bit strange for me. What about the idea of creating a module
> >  > 'XForms for HTML Form authors' that just defines how those elements
> >  > map to Core XForms. Over time we can migrate those features to Core
> >  > XForms if we think that they are an improvement to the Core 
language.
> >  >
> >  >
> >  > I know that this response is a bit high level, and not concrete. 
But
> >  > I will respond in more detail after the group has had time to
> >  > respond to this e-mail.
> >  >
> >  > Regards,
> >  >
> >  > Nick Van den Bleeken  -  Research & Development Manager
> >  > Inventive Designers
> >  > Phone: +32 - 3 - 8210170
> >  > Fax: +32 - 3 - 8210171
> >  > Email: Nick_Van_den_Bleeken@inventivegroup.com
> >  >
> >  > public-forms-request@w3.org wrote on 04/11/2008 02:44:55 AM:
> >  >
> >  > >
> >  > > To feed the Forms Joint Task Force discussion on "Architecture of
> >  > > Forms", I think it makes sense to succinctly state the principles
> >  > > that are guiding the design of the XForms 1.2 syntax.  This is 
only
> >  > > my take on it, and I hope this can be honed and refined through
> >  > > group discussion this week and early next week so we can send
> >  > > something like this out to the task force later next week.
> >  > >
> >  > >
> >  > > 1) The same forms vocabulary must be expressible in XML syntax 
and a
> >  > > non-XML web syntax.
> >  > >
> >  > >
> >  > > 2) The forms vocabulary must leverage terms from W3C 
Recommendations
> >  > > where it is possible to do so in lieu of new terms.  Simple
> >  > > extensions to existing terms must take priority over new terms.
> >  > >
> >  > >
> >  > > 3) The forms vocabulary must allow a seamless mapping from a
> >  > > conceptual single-layer authoring style to the model-view-
> >  > > controller-submission architecture of XForms.
> >  > >
> >  > > This is the fundamental goal of the task force communicated in 
the
> >  > > WG charters as well as being another way of saying principles #1 
and
> > #2.
> >  > >
> >  > >
> >  > > 4) The forms vocabulary must allow the use of terms familiar to
> >  > > today's web authors for the conceptual single-layer authoring 
style.
> >  > >
> >  > > This is a facet of principle #2 as applied to the HTML 
Recommendation.
> >  > >
> >  > >
> >  > > 5) The forms vocabulary must allow the terms that map to the 
XForms
> >  > > architecture to be extended to terms that are unique to the HTML
> >  > > forms presentational layer.
> >  > >
> >  > > For example, a named div in HTML corresponds to a named group in
> >  > > XForms vocabulary.  This is necessary because of the precedence 
of
> >  > > div in the W3C HTML Recommendation (principle #1).  However, this 
is
> >  > > not intended to allow new feature creation with terms that ignore
> >  > > obvious existing terms in other recommendations like XForms 
(principle
> > #2).
> >  > >
> >  > >
> >  > > 6) The forms vocabulary must allow incremental author opt-in of 
the
> >  > > key components and processing models of XForms as they are 
needed.
> >  > >
> >  > > This is a facet of principle #2 as applied to XForms.
> >  > >
> >  > > 6a) instance for declaring a block of XML.
> >  > > 6b) submission once server communication of XML data is needed
> >  > > during form execution
> >  > > 6c) bind for declaring calculations of data values and properties 
on
> >  > > declared blocks of XML
> >  > > 6d) Single node binding attributes (e.g. ref) for attaching form
> >  > > controls to declared XML data
> >  > > 6e) Access to setvalue, insert and delete as actions and as DOM
> >  > > script functions as data manipulation needs arise
> >  > > 6f) group as form control aggregation needs arise
> >  > > 6g) repeat and setindex as row-based content duplication needs 
arise
> >  > > 6h) switch and toggle as conditional content needs arise
> >  > > 6i) output as display needs arise for calculated results or
> >  > declared XML data
> >  > > 6j) other controls such as select1, trigger, submit as the needs 
for
> >  > > their semantics arise
> >  > >
> >  > >
> >  > > 7) The forms vocabulary must allow a named form control to be
> >  > > synonymous with the datum it collects, thereby implying a data 
layer.
> >  > >
> >  > > This is an aspect of principle #3.
> >  > >
> >  > > 7a) In order to imply a data layer, there must be a containment
> >  > > element to define the collection of controls included in the data
> >  > > layer.  Due to principle #2 and #4, this must be the form tag.
> >  > > 7b) A means of naming the form controls is needed.  Due to 
principle
> >  > > #2 as applied to HTML, this needs to be the 'name' attribute.
> >  > >
> >  > >
> >  > > 8) The forms vocabulary must allow the data layer to be 
hierarchic
> >  > > based on hierarchy expressed in the user interface.
> >  > >
> >  > > 8a) It must be possible to express simple hierarchy with a named
> >  > > group element.
> >  > > 8b) It must be possible to express conditional hierarchic content
> >  > > with a named switch element.
> >  > > 8c) It must be possible to express repeated hierarchic content 
with
> >  > > a named repeat element.
> >  > > 8d) It must be possible for data hierarchy to be implied by the 
name
> >  > > attribute so that HTML to use other grouping elements like div.
> >  > >
> >  > >
> >  > > 9) The forms vocabulary must allow simple declarative XPath
> >  > > expressions for dynamic data value and property calculations.
> >  > >
> >  > > 9a) The expressions must be able to access the data layer using a
> >  > > simple XPath variable syntax that maintains the flat model
> >  > > conceptualization familiar to web authors
> >  > > 9b) The expressions must be able to access the data layer using
> >  > > simple XPath location paths that follow the structure of the user
> >  > > interface.  An expression in a form control attribute must be 
able
> >  > > to access the value of a sibling form control with a location 
path
> >  > > containing zero slashes.
> >  > > 9c) Aside from the XForms precedence of using XPath for these
> >  > > expressions (principle #2), XPath is used in lieu of javascript
> >  > > because it avoids conflicts arising from ability to mutate the 
DOM
> >  > > with javascript functions, which conflicts with the intent of the
> >  > > declarative calculation system.
> >  > >
> >  > >
> >  > > 10) The forms vocabulary must allow properties of a datum to be
> >  > > expressed as attributes of the corresponding form control in the
> >  > > conceptual single-layer authoring style.
> >  > >
> >  > > 10a) An attribute called "calculate" must be used to express an
> >  > > XPath for the value of the datum (and hence the form control).
> >  > > 10b) An attribute called "relevant" must be used to express an 
XPath
> >  > > for whether the data and form control are suitable for rendition
> >  > andsubmission
> >  > > 10c) An attribute called "readonly" must be used to express an 
XPath
> >  > > for whether the data is modifiable.  For compatibility, the 
special
> >  > > keywords 'readonly' and 'true' must be recognized before
> >  > > interpreting the attribute content as an XPath
> >  > > 10d) An attribute called "datatype" must be used to associate an
> >  > > XForms or XML schema datatype with the data of the form control.
> >  > > This attribute is mapped to the "type" attribute from XForms, but
> >  > > the name "datatype" is used due to the use of preceding use of
> >  > > "type" in HTML form controls.
> >  > >
> >  > >
> >  > > 11) The forms vocabulary must allow dynamic change to the
> >  > > presentation via mutation of the data layer.
> >  > >
> >  > > 11a) The data manipulation actions of XForms (insert, delete,
> >  > > setvalue) must be exposed to Javascript with sensible parameter
> >  > > defaults that keep authoring simple and based on the names
> >  > > established by the name attribute on form controls.
> >  > > 11b) It must also be possible to express mutations as declarative
> >  > > form control event handlers.
> >  > > 11c) It must be possible to express dynamic interactive web
> >  > > applications without explicit use of javascript.
> >  > >
> >  > >
> >  > > 12) The forms vocabulary terms must work in HTML with no 
namespace
> >  > > qualification.
> >  > >
> >  > > 12a) Attributes derived from XML events must be imported, 
especially
> >  > > event, target and phase.
> >  > > 12b) Elements and attributes from XForms must be imported.
> >  > > 12c) The null namespace must automatically used for the implied 
data
> > layer
> >  > > 12d) The instance element from XForms needs work to ensure that
> >  > > unqualified data content is regarded as being in the empty 
namespace.
> >  > >
> >  > > Cheers,
> >  > > John M. Boyer, Ph.D.
> >  > > Senior Technical Staff Member
> >  > > Lotus Forms Architect and Researcher
> >  > > Chair, W3C Forms Working Group
> >  > > Workplace, Portal and Collaboration Software
> >  > > IBM Victoria Software Lab
> >  > > E-Mail: boyerj@ca.ibm.com
> >  > >
> >  > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> >  > > Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/
> >  > > JohnBoyer?flavor=rssdw
> > > Inventive Designers' Email Disclaimer:http://
> >  > www.inventivedesigners.com/email-disclaimer
> > ________________________________
> >
> >
> >
> >
> > Inventive Designers' Email Disclaimer:
> > http://www.inventivedesigners.com/email-disclaimer
> >
> 
> 
> 
> -- 
>  Mark Birbeck
> 
>  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
>  http://www.x-port.net | http://internet-apps.blogspot.com
> 
>  x-port.net Ltd. is registered in England and Wales, number 03730711
>  The registered office is at:
> 
>  2nd Floor
>  Titchfield House
>  69-85 Tabernacle Street
>  London
>  EC2A 4RR


--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer