W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2004

[whatwg] several mail addresses in input type email?

From: Edmund Lai <edmund.lai@gmail.com>
Date: Thu, 8 Jul 2004 21:15:41 -0700
Message-ID: <39fef8d404070821151f5ff2dd@mail.gmail.com>
On Wed, 7 Jul 2004 16:56:39 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 7 Jul 2004, Edmund Lai wrote:
> >
> > What I am proposing is that WHATWG datatype should be a superset of
> > XML Schema Part 2: Datatype,.
> 
> Yes, but can you explain exactly what you mean by this? What syntax would
> this involve?
> 

OK, here is what I mean.

Just like style can be defined in a stylesheet or inline, datatype can
be defined in a type definition or inline.

Here is a type copied from Eric van der Vlist, the namespace prefix is removed

  <simpleType name="multipleOfTen">
    <restriction base="integer">
      <pattern value=".*0"/>
    </restriction>
  </simpleType>

Other examples are

  <simpleType name="listOfUnions">
    <list>
      <simpleType>
        <union memberTypes="date integer"/>
      </simpleType>
    </list>
  </simpleType>
  

  <simpleType name="UnionOfLists">
    <union>
      <simpleType>
        <list itemType="date"/>
      </simpleType>
      <simpleType>
        <list itemType="xs:integer"/>
      </simpleType>
    </union>
  </simpleType>

Then we can use the type "multipleOfTen" in multiple places

  <input id="input1" name="input1" type="multipleOfTen" value="20" />
  <input id="input2" name="input2" type="multipleOfTen" value="40" />

Anything that is allowed in XML Schema Part2: datatype can be defined
this way. This include
union, list, list of union, union of list etc.

To do it inline would be more difficult. It would require the input
element to have child element. If we do not want to allow child
elements in input, then we can only do restriction inline (actually we
can also do simple list and simple union inline, I shall discuss that
if we decide to go that route. In which case it would be similar to
WF2 now, except we should use the same terminlogy as XML schema when
the facets are the same, so we should use maxInclusive, minInclusive
instead of just max and min. And we should have maxExclusive and
minExclusive.

  <input id="input1" name="input1" type="integer" pattern=".*0" value="20" />
  <input id="input2" name="input2" type="integer" pattern=".*0" value="40" />

However for list of unions and union of lists you have to define the
datatype first.

> 
> > Then we can have list and union of datatypes.
> 
> If that is the only reason to use XML Schema datatypes, there are
> definitely better ways to achive that goal. As I have pointed out, the XML
> Schema datatypes have a large number of problems which would make
> importing them into HTML much more work than it is worth, IMHO.
>

I have been working on this using JavaScript, I really don't see it
being a lot of work. Besides, why reinvent the wheel?
 
> 
> > We can define a datatype once and use it in different places of the web
> > page.
> 
> Could you give an example of how this would work?
>

The example above shows how this would work.
 
> 
> > Again I want to reiterate that XML Schema Part 2: Datatype only concerns
> > simpleType and not complexType, so it would not have the complexities of
> > the full schema language.
> 
> The complexities of XML Schema Part 2 are what is worrying me! :-)
> 

I really don't see part 2 to be that complex (part 1 is a different
matter). Furthermore as I shown in the example above, if the user
don't want to do anything fancy, then it is not too different from
what is in WF2 now. The ideal
design is that simple thing should be simple, complicated thing should
be possible. IMHO, the current WF2 datatype design only shoot for the
first half and not the second half.

> 
> 
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Thursday, 8 July 2004 21:15:41 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:35 UTC