W3C home > Mailing lists > Public > www-forms@w3.org > May 2006

RE: XForms Basic and Schema Validation

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 9 May 2006 15:17:57 +0100
To: <www-forms@w3.org>
Message-ID: <000801c67373$5f529a00$7e01a8c0@Jan>

Hi David,

Well, I wasn't being unfriendly--terse, yes--but if John read it like that
then I do feel bad, and I unreservedly apologise. Also, I was being serious
that asking Henry was a good idea! But at the same time I was also saying
that I think the XML Schema spec is quite clear on this (that doesn't mean
it's easy to read, though).

Anyway, I don't believe that Henry is saying that "datatypes are not simple
types", and I think the best thing is if I go through his points, as well as
throw in some points from the XML Schema spec. If you or John still disagree
with me, at least you can see what parts of the spec I'm referring to, and
can refute and clarify the references more specifically.

First Henry says:

  In W3C XML Schema, datatypes are to a certain extent an
  abstraction -- the combination of a lexical space, a value
  space and a mapping between them -- that is meant to be
  usable via a range of concrete mechanisms.

As we know, this means that a datatype is a combination of the characters
that make up a value (the lexical space) and the values that they represent
(the value space). So in lexical space, a string can be "123" and an integer
can also be "123", but their *value* spaces are very different, since one is
'a string' and one is 'an integer'.

The point that Henry makes about being "to a certain extent an abstraction"
relates to the fact that the various 'types' in XML Schema are to some
extent defined in such a way that they can be used independently of specific
mechanisms. So you have these 'abstract' things which need a mechanism to
define them. Henry goes on to say that the mechanism for datatypes is the
"Simple Type Definition":

  W3C XML Schema itself has such a concrete mechanism:
  the Simple Type Definition component.

So, I think that's clear enough that the term 'datatype' is referring to
'simple types'. If this is not convincing enough, then we can also look at
the scope of the datatypes document:

  This portion of the XML Schema Language discusses datatypes
  that can be used in an XML Schema. These datatypes can be
  specified for element content that would be specified as
  #PCDATA and attribute values of various types in a DTD.
  It is the intention of this specification that it be usable
  outside of the context of XML Schemas for a wide range of
  other XML-related activities such as [XSL] and [RDF Schema].
  [1]

Henry then goes on to look at where these simple types can be used. The
first two are quite easy, so let's deal with them first:

 This in turn may appear and function in three contexts:
  1) As the {type definition} of an Attribute Declaration;
  2) As the {type definition} of an Element Declaration;

Henry is pointing out that an attribute or an element can contain simple
type content. I should say though, that in the second case this should be
qualified to say that it is only applicable when the element has no further
elements as children. The XML Schema spec puts it like this:

  A simple type definition is a set of constraints on strings and
  information about the values they encode, applicable to the
  .normalized value. of an attribute information item or of an
  element information item with no element children. Informally,
  it applies to the values of attributes and the text-only content
  of elements. [2]

Whilst we're here, it's worth pointing out that *by definition* simple types
are created by restricting some other simple type, which means that to get
you started XML Schema must provide a set of 'built-in' simple types. These
are referred to as datatypes, as the previously quoted section goes on to
say:

  Each simple type definition, whether built-in (that is, defined
  in [XML Schemas: Datatypes]) or user-defined, is a .restriction.
  of some particular simple .base type definition..

Anyway, we've established that simple types are used to set the *content* of
attributes as well as the *content* of elements (provided that they can have
content, and also have no child elements). But in XML Schema you need more
than just the values that go *inside* the attributes and elements, you need
to specify the relationship between elements and attributes. As we know,
this relationship is defined using 'complex types', but there are two types
of complex types, those which have 'simple content' and those which have
'complex content'.

To illustrate this, let's return to the point that Henry was making in his
second bullet, and we should be able to see where the notions of 'simple
content' and 'complex content' come from. Recall that we can use simple
types in elements that have no children, and I'll reuse the example of such
a set-up I gave in a previous post:

  <length unit="cm">25</length>

Here we are using simple types to define the contents of @unit as well as
the contents of <length>. Compare that mark-up to a structure like this:

  <length>
    <value>25</value>
    <unit>cm</unit>
  </length>

Here simple types are used for the content of <unit> and <value>, but
crucially, the content of <length> is other elements.

In both of these examples we have a complex type, but in the first example
the 'content type' is called 'simple content' and in the second example the
'content type' is called 'complex content'. According to the spec:

  A complex type definition is a set of attribute declarations and a
  content type, applicable to the [attributes] and [children] of an
  element information item respectively. [3]

In other words, when you define a complex type you need two things; a whole
bunch of attribute declarations, and the definition of the content type. The
spec goes on to describe 'content type':

  The content type may require the [children] to contain neither
  element nor character information items (that is, to be empty),
  to be a string which belongs to a particular simple type or to
  contain a sequence of element information items which conforms
  to a particular model group, with or without character
  information items as well.

This simply means that the content of a complex type can be:

  * empty;
  * a simple type;
  * child elements (and perhaps mixed content).

This is what Henry is referring to in his 3rd point--that a simple type may
appear as *part of* the definition of a complex type, when the complex type
specifies that the element only has a string of text for its content:

  3) As the {content type} of a Complex Type Definition (which
     itself will typically be the {type definition} of an Element
     Declaration).

However, using a simple type in this way would not result in another simple
type--i.e., a pattern for expressing the *contents* of an attribute or
element--it would result in the definition of a complex type--i.e., a
pattern for an element with text content, and possibly some attributes.

So, to recap the terminology, using the examples I gave before:

  <length unit="cm">25</length>

  <length>
    <value>25</value>
    <unit>cm</unit>
  </length>

1. Both of these would require a Complex Type Definition to
   describe them.

2. The first example is a complex type with 'simple content'.

3. The second is a complex type with 'complex content'.

4. In the first, the contents of <length> and @unit are
   simple types.

5. In the second the contents of <unit> and <value> are also
   simple types.


I hope this clarifies the terminology that we should be using, and that in
both the XForms Basic spec and John's email terms were not being used
correctly.

I won't restate my position on the XForms Basic spec since this is more
about trying to clarify the terms used in our discussion.

Regards,

Mark

[1] http://www.w3.org/TR/xmlschema-2/#scope

[2] 2.2.1.2 Simple Type Definition
    XML Schema Part 1: Structures Second Edition
    http://www.w3.org/TR/xmlschema-1/

[3] 2.2.1.3 Complex Type Definition
    XML Schema Part 1: Structures Second Edition
    http://www.w3.org/TR/xmlschema-1/


Mark Birbeck
CEO
x-port.net Ltd.

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

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

> -----Original Message-----
> From: David Landwehr [mailto:david.landwehr@solidapp.com] 
> Sent: 09 May 2006 13:25
> To: Mark Birbeck
> Cc: www-forms@w3.org
> Subject: Re: XForms Basic and Schema Validation
> 
> Dear Mark,
> 
> I asked the XML Schema working group about this since I 
> understood from the discussion that datatypes either 
> corresponds to a simple type (I believe you wrote that) or to 
> validation of simple content (which I believe John wrote). I 
> had my problems reading which one of these interpretations 
> were correct and when to get help from Henry.
> 
> I think you are a bit unfriendly since I only want this 
> discussion to produce a good result. I certainly don't 
> understand that you write "although I think the XML Schema 
> spec is also pretty clear on this" when you wrote to John 
> "Datatypes *are* simple types!", which from Henry's mail is incorrect.
> 
> I will leave you to sort it out,
> David
> 
> Mark Birbeck wrote:
> > David,
> >
> > Great...although I think the XML Schema spec is also pretty 
> clear on this.
> >
> > Regards,
> >
> > Mark
> >
> >
> > Mark Birbeck
> > CEO
> > x-port.net Ltd.
> >
> > e: Mark.Birbeck@x-port.net
> > t: +44 (0) 20 7689 9232
> > b: http://internet-apps.blogspot.com/
> > w: http://www.formsPlayer.com/
> >
> > Download our XForms processor from
> > http://www.formsPlayer.com/
> >
> >
> >   
> >> -----Original Message-----
> >> From: David Landwehr [mailto:david.landwehr@solidapp.com]
> >> Sent: 09 May 2006 10:38
> >> To: Mark Birbeck
> >> Cc: www-forms@w3.org
> >> Subject: Re: XForms Basic and Schema Validation
> >>
> >> Hi,
> >>
> >> I took the liberty to ask the XML Schema WG what the term datatype 
> >> are meant to be. Henry gave the very good answer here:
> >> http://lists.w3.org/Archives/Public/xmlschema-dev/2006May/0008.html
> >>
> >> I hope this can help this discussion which I feel is very 
> important 
> >> for XForms.
> >>
> >> Best regards,
> >> David
> >>
> >>
> >> Mark Birbeck wrote:
> >>     
> >>> Hi John,
> >>>
> >>> 1. Simple types and simple content are two different things.
> >>> 2. Datatypes *are* simple types!
> >>>  
> >>> Regards,
> >>>  
> >>> Mark
> >>>
> >>>
> >>> Mark Birbeck
> >>> CEO
> >>> x-port.net Ltd.
> >>>
> >>> e: Mark.Birbeck@x-port.net
> >>> t: +44 (0) 20 7689 9232
> >>> b: http://internet-apps.blogspot.com/
> >>> w: http://www.formsPlayer.com/
> >>>
> >>> Download our XForms processor from
> >>> http://www.formsPlayer.com/
> >>>
> >>>  
> >>>
> >>> ________________________________
> >>>
> >>> From: John Boyer [mailto:boyerj@ca.ibm.com]
> >>> Sent: 08 May 2006 22:32
> >>> To: Mark Birbeck
> >>> Cc: www-forms@w3.org; www-forms-request@w3.org
> >>> Subject: RE: XForms Basic and Schema Validation
> >>>
> >>>
> >>>
> >>> 	
> >>> 	Hi Mark,
> >>> 	
> >>> 	The notion of datatype is orthogonal to simple vs. 
> >>>       
> >> complex type. 
> >>     
> >>> 	
> >>> 	Section 2.2.1.3 of Schema Part 1 is clear in defining
> >>>       
> >> the fact that
> >>     
> >>> you can have a complex type with simple content.   
> >>> 	And you can datatype validate the simple content of a
> >>>       
> >> complex type. 
> >>     
> >>> 	
> >>> 	>I agree if you were using the term datatype in its
> >>>       
> >> proper sense.
> >>     
> >>> But
> >>> 	>datatypes are simple types, not complex ones, so I
> >>>       
> >> disagree, since
> >>     
> >>> it sounds
> >>> 	>like you are using it to cover complex types. 
> >>> 	
> >>> 	I am using datatype in its proper sense, which is also
> >>>       
> >> what the spec
> >>     
> >>> is doing, I believe.
> >>> 	Datatypes are not simple types.  They are descriptions
> >>>       
> >> of string
> >>     
> >>> validations, which can
> >>> 	be used to validate content of both simple and complex types. 
> >>> 	
> >>> 	>Well...firstly it actually says "XML Schema datatypes" 
> >>>       
> >> which to me
> >>     
> >>> means
> >>> 	>'the datatypes from XML Schema Part 2'. In other
> >>>       
> >> words, it doesn't
> >>     
> >>> deal with
> >>> 	>other types defined by an author.
> >>> 	
> >>> 	Sorry, but you are misreading "XML Schema datatypes" as
> >>>       
> >> "XML Schema
> >>     
> >>> built-in datatypes".
> >>> 	If XForms Basic had intended to refer to the built-in
> >>>       
> >> datatypes, it
> >>     
> >>> should have used
> >>> 	that term.  But XML Schema Part 2 is about providing
> >>>       
> >> the machinery
> >>     
> >>> for defining ones own
> >>> 	datatypes. It then uses that machinery to create a
> >>>       
> >> number of built-in
> >>     
> >>> datatypes.  Note
> >>> 	that the built-in datatypes can be used in complex
> >>>       
> >> types that define
> >>     
> >>> simple content.
> >>> 	
> >>> 	So, we are left with the fact that XForms 1.0 was
> >>>       
> >> designed to address
> >>     
> >>> the *main* use
> >>> 	case for validation, which is user input validation.  
> >>>       
> >> That's why the
> >>     
> >>> spec contains
> >>> 	language associating the type MIP with schema datatype. 
> >>>       
> >> If anything
> >>     
> >>> more than that works
> >>> 	for an implementation, it seems to me to be a bit of a
> >>>       
> >> bonus for that
> >>     
> >>> implementation.
> >>> 	
> >>> 	John M. Boyer, Ph.D.
> >>> 	Senior Product Architect/Research Scientist
> >>> 	Co-Chair, W3C XForms Working Group
> >>> 	Workplace, Portal and Collaboration Software
> >>> 	IBM Victoria Software Lab
> >>> 	E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
> >>> 	
> >>> 	Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> >>> 	
> >>> 	
> >>> 	
> >>> 	
> >>> 	
> >>> 	"Mark Birbeck" <mark.birbeck@x-port.net> 
> >>> 	Sent by: www-forms-request@w3.org
> >>>
> >>> 	05/08/2006 05:33 AM
> >>>
> >>> 		
> >>> 		To
> >>> 		<www-forms@w3.org> 
> >>> 		cc
> >>> 		
> >>> 		Subject
> >>> 		RE: XForms Basic and Schema Validation
> >>>
> >>> 		
> >>>
> >>>
> >>>
> >>>
> >>> 	
> >>> 	Hi John,
> >>> 	
> >>> 	Here's an 'executive summary' of the points that I'll provide 
> >>> explanation
> >>> 	for, inline below:
> >>> 	
> >>> 	 One problem with XForms Basic as defined is that it doesn't
> >>> 	 explain how the 'downgrading' of a complex type should take
> >>> 	 place. The second bullet (in XForms Basic) provides for the
> >>> 	 *possibility* of this downgrading by saying that a processor
> >>> 	 "may" choose to only support simple types, but nowhere is it
> >>> 	 explained what it would mean in practice. (And in reply to
> >>> 	 your and Raman's view that the third bullet deals with this,
> >>> 	 I'm afraid it doesn't--it deals with *datatypes*, which are
> >>> 	 simple types.)
> >>> 	
> >>> 	
> >>> 	>                 The sentence says that all Schema 
> >>>       
> >> datatypes other
> >>     
> >>> than the
> >>> 	> ones listed are to be treated as string, not all
> >>>       
> >> built-in schema
> >>     
> >>> 	> datatypes.
> >>> 	
> >>> 	Well...firstly it actually says "XML Schema datatypes" 
> >>>       
> >> which to me
> >>     
> >>> means
> >>> 	'the datatypes from XML Schema Part 2'. In other words,
> >>>       
> >> it doesn't
> >>     
> >>> deal with
> >>> 	other types defined by an author.
> >>> 	
> >>> 	But even if you ignore the "XML Schema" bit, the term used is 
> >>> 'datatype'
> >>> 	which has a very specific meaning; to infer that this sentence 
> >>> suggests that
> >>> 	any *complex* type that the author has defined should also be 
> >>> converted to
> >>> 	xs:string, would require you to include 'complex types' 
> >>>       
> >> within the
> >>     
> >>> 	definition of 'datatypes' which--as you rightly say in
> >>>       
> >> a discussion
> >>     
> >>> with
> >>> 	Allan on that very subject-- is incorrect. :)
> >>> 	
> >>> 	I suppose you could say that using the word 'datatype' 
> >>>       
> >> was a mistake,
> >>     
> >>> and
> >>> 	what was actually intended was the more general term 'type 
> >>> definition'; but
> >>> 	that makes things worse, since this term includes both
> >>>       
> >> simple and
> >>     
> >>> complex
> >>> 	types, so the third bullet would actually be saying
> >>>       
> >> that any type
> >>     
> >>> definition
> >>> 	other than those listed would be xs:strings--obviously
> >>>       
> >> not what is
> >>     
> >>> intended.
> >>> 	
> >>> 	So my suggestion is for the WG to stop trying to rush
> >>>       
> >> this out, and
> >>     
> >>> properly
> >>> 	resolve the issue of how complex types behave. (The
> >>>       
> >> spec hasn't moved
> >>     
> >>> for
> >>> 	about 2 1/2 years, I think another week isn't going to hurt.)
> >>> 	
> >>> 	As it happens, I don't really see anything wrong with the third 
> >>> bullet in
> >>> 	relation to its stated subject matter which is
> >>>       
> >> datatypes. All it says
> >>     
> >>> is
> >>> 	that for some datatypes you don't need to provide any
> >>>       
> >> special regular
> >>     
> >>> 	expressions if you are doing a 'subset processor'.
> >>> 	
> >>> 	
> >>> 	However, the big thing that *is* glaringly missing is
> >>>       
> >> the bridge from
> >>     
> >>> the
> >>> 	goal that has been described (of not requiring an XForms Basic 
> >>> processor to
> >>> 	have a full XML Schema implementation) and the reality
> >>>       
> >> of the prose;
> >>     
> >>> we need
> >>> 	something very clear that explains how a Basic processor should 
> >>> proceed if
> >>> 	it is going to 'downgrade' complex types.
> >>> 	
> >>> 	In working through some kind of proposal for this, it
> >>>       
> >> seems to me
> >>     
> >>> that
> >>> 	mapping to xs:string may not actually be the best
> >>>       
> >> solution. I'll try
> >>     
> >>> to
> >>> 	explain, and people can say what they think.
> >>> 	
> >>> 	
> >>> 	Looking at the entirety of XML Schema, I would say that
> >>>       
> >> what we're
> >>     
> >>> after is
> >>> 	the following behaviour for a 'subset' schema processor:
> >>> 	
> >>> 	 * a reference to any undefined type is an error;
> >>> 	
> >>> 	 * any *datatype* that is not in the list in
> >>> 	   bullet 3 has a regular expression that is
> >>> 	   equivalent to xs:string;
> >>> 	
> >>> 	 * any *simple* type is processed as normal (i.e.,
> >>> 	   as it would be in Full);
> >>> 	
> >>> 	 * any *complex* type is processed as if it were
> >>> 	   a simple type, with all element and attribute
> >>> 	   definitions ignored.
> >>> 	
> >>> 	The first point may or may not be implicit in our
> >>>       
> >> schema processing
> >>     
> >>> anyway,
> >>> 	but I think it needs some clarification. However, we
> >>>       
> >> can ignore it
> >>     
> >>> for this
> >>> 	discussion since it should really be defined in XForms
> >>>       
> >> Full anyway.
> >>     
> >>> 	
> >>> 	The second point, on the behaviour of datatypes, is
> >>>       
> >> already given by
> >>     
> >>> bullet
> >>> 	3 in the spec, so we need do nothing here either.
> >>> 	
> >>> 	Similarly, on the third point, the behaviour of simple types is 
> >>> already
> >>> 	given by bullet 2 in the spec, and although it might
> >>>       
> >> benefit from
> >>     
> >>> 	clarification, it's at least there in part.
> >>> 	
> >>> 	So all we need is an extra bullet that clarifies how
> >>>       
> >> complex types
> >>     
> >>> are
> >>> 	converted, and here I'm proposing *not* that they are
> >>>       
> >> automatically
> >>     
> >>> 	converted to strings--which is the current
> >>>       
> >> proposal--but that the
> >>     
> >>> 	*structural* features are ignored.
> >>> 	
> >>> 	
> >>> 	The following example is given in the XML Schema
> >>>       
> >> specification of how
> >>     
> >>> an
> >>> 	element 'width' can have a value which is a
> >>>       
> >> non-negative integer, as
> >>     
> >>> well as
> >>> 	an attribute which indicates the unit of that
> >>>       
> >> non-negative integer:
> >>     
> >>> 	
> >>> 	 <xs:complexType name="length1">
> >>> 	   <xs:simpleContent>
> >>> 	     <xs:extension base="xs:nonNegativeInteger">
> >>> 	       <xs:attribute name="unit" type="xs:NMTOKEN"/>
> >>> 	     </xs:extension>
> >>> 	   </xs:simpleContent>
> >>> 	 </xs:complexType>
> >>> 	
> >>> 	 <xs:element name="width" type="length1" />
> >>> 	
> >>> 	 <width unit="cm">25</width>
> >>> 	
> >>> 	As far as I can see a processor that can handle simple
> >>>       
> >> types (which
> >>     
> >>> all
> >>> 	Basic processors will do) can process the example I
> >>>       
> >> just gave, as
> >>     
> >>> easily as
> >>> 	they can process the following:
> >>> 	
> >>> 	 <xs:simpleType name="length1">
> >>> 	   <xs:restriction base="xs:nonNegativeInteger" />
> >>> 	 </xs:simpleType>
> >>> 	
> >>> 	By doing this, at very little cost we reduce the gap
> >>>       
> >> between XForms
> >>     
> >>> Basic
> >>> 	and XForms Full. (From the XML Schema terminology point
> >>>       
> >> of view, what
> >>     
> >>> I'm
> >>> 	saying is that since:
> >>> 	
> >>> 	 simple content = simple type + attributes
> >>> 	
> >>> 	we can 'remove' the attributes and still make use of
> >>>       
> >> the simple type
> >>     
> >>> 	definition, rather than just saying 'string'.)
> >>> 	
> >>> 	
> >>> 	>                 "In my opinion" This is why any 
> >>>       
> >> attempt to assign
> >>     
> >>> a datatype
> >>> 	> other than the ones listed should be regarded as string.
> >>> 	
> >>> 	I agree if you were using the term datatype in its
> >>>       
> >> proper sense. But
> >>     
> >>> 	datatypes are simple types, not complex ones, so I
> >>>       
> >> disagree, since it
> >>     
> >>> sounds
> >>> 	like you are using it to cover complex types.
> >>> 	
> >>> 	
> >>> 	>                 At a higher level, the purpose of basic was
> >>> exactly so that
> >>> 	> basic processors did not have to do a very smart
> >>>       
> >> schema engine.
> >>     
> >>> 	>                 This goal does not seem to be 
> >>>       
> >> achieved if basic
> >>     
> >>> processors
> >>> 	> have to be smart enough to read the schema
> >>>       
> >> definitions to figure
> >>     
> >>> 	>                 out that the datatype is undefined.
> >>> 	
> >>> 	That's a slightly different issue. The processor has to
> >>>       
> >> process the
> >>     
> >>> XML
> >>> 	Schema mark-up anyway, in order to find the simple
> >>>       
> >> types. Spotting
> >>     
> >>> undefined
> >>> 	types should be easy.
> >>> 	
> >>> 	
> >>> 	>                 "In my opinion" An implementation 
> >>>       
> >> should be able
> >>     
> >>> to write
> >>> 	> lexical analyzers for just those 26 given datatypes, and apply
> >>> 	> the write analyzer for the given datatype and otherwise it
> >>> 	> should be able to pretend that the type assignment refers to
> >>> 	> string.
> >>> 	
> >>> 	I understand the goal, and explained that in my
> >>>       
> >> post...but I still
> >>     
> >>> don't
> >>> 	like the fact that you can't predict what the platform you are 
> >>> running on
> >>> 	will do. I really don't think it's a good idea to allow
> >>>       
> >> Basic to
> >>     
> >>> 'maybe' do
> >>> 	this or 'maybe' do that. I would prefer to see the
> >>>       
> >> behaviour defined
> >>     
> >>> clearly
> >>> 	and then for us to say that this is how a Basic processor will 
> >>> behave.
> >>> 	However, I'm happy to leave that issue to one side
> >>>       
> >> whilst we actually
> >>     
> >>> sort
> >>> 	out the lack of clarity on the behaviour.
> >>> 	
> >>> 	Regards,
> >>> 	
> >>> 	Mark
> >>> 	
> >>> 	
> >>> 	Mark Birbeck
> >>> 	CEO
> >>> 	x-port.net Ltd.
> >>> 	
> >>> 	e: Mark.Birbeck@x-port.net
> >>> 	t: +44 (0) 20 7689 9232
> >>> 	b: http://internet-apps.blogspot.com/
> >>> 	w: http://www.formsPlayer.com/
> >>> 	
> >>> 	Download our XForms processor from
> >>> 	http://www.formsPlayer.com/
> >>> 	
> >>> 	
> >>> 	
> >>> 	
> >>> 	
> >>>
> >>>
> >>>
> >>>
> >>>   
> >>>       
> >> --
> >> --------------------------------------------
> >> David Landwehr (david.landwehr@solidapp.com) Chief 
> Executive Officer, 
> >> SolidApp
> >> Web: http://www.solidapp.com
> >> Office: +45 48268212
> >> Mobile: +45 24275518
> >> --------------------------------------------
> >>
> >>
> >>     
> >
> >
> >
> >   
> 
> 
> --
> --------------------------------------------
> David Landwehr (david.landwehr@solidapp.com) Chief Executive 
> Officer, SolidApp
> Web: http://www.solidapp.com
> Office: +45 48268212
> Mobile: +45 24275518
> --------------------------------------------
> 
> 
Received on Tuesday, 9 May 2006 14:19:28 GMT

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