[whatwg] several mail addresses in input type email?

[Edmund Lai]

What I am talking is not about specific built-in type. What really
counts is user derived type. Remember the original thread is that we
have a email address type and then there is request for multiple email
address type. If we adopt XML schema datatype, this is not a problem,
we just do a derivation by list. Dervation by union can also be very
useful. And you can use devied type in input type instead of repeating
the same parameter over and over again in every input element of that
type. This can be compared to how stylesheet make our life easier.

On Thu, 1 Jul 2004 00:58:35 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> 
> On Wed, 30 Jun 2004, Edmund Lai wrote:
> > >
> > > Why? Is there any advantage to using the (complex) data type structure of
> > > XML Schema rather than simply extending the existing HTML4 data types?
> >
> > The first advantage is that we have an established comprehesive datatype
> > standard that has been tested and used extensively. The standard goes
> > beyond what is proposed here. So there is no reason to revent it again.
> > As more and more people are getting familiar with the W3C XML schema
> > datatypes, developers do not need to learn two set of datatype standard
> > and this would reduce the learning curve.
> 
> It isn't really clear to me that it has been used that extensively, and I
> am not really aware of any testing, but ok.
> 
> 
> > The second advantage is that as more and more data are stored in XML
> > format described by XML schema, developer who wants to use WF2(Web Forms
> > 2.0) to enter their XML data would have a easier time if the same
> > datatype described in XML schema can be used WF2. In fact the process
> > can be automated by some tool.
> 
> I'm not sure what you mean. How would you convert a field with type IDREFS
> into a form control? Or a field with type NOTATION?
> 
> 
> > The third advantage is that if we can have type definition, then let say
> > we have a datatype with a long and complicated pattern used in 10
> > different places, we don't ned have that pattern in 10 different places.
> 
> If we can have a type definition, then we are including a lot more than
> just XML Schema Part 2.
> 
> 
> > Actually what is needed is that every datatype in XML schema can be
> > represented by a type in WF2, and not the other around. The goal is that
> > every XML element can be presented as a web form element. The goal is
> > not every web form element can be represented by an XML element.
> 
> Every XML element _can_ be represented as a type in WF2: every attribute
> in XML is basically type="text".
> 
> But assuming you mean that every simple type in XML Schema should be
> representable in a form, this is already possible, with the exception of
> "duration" which is currently on the WF3 requirements list and gMonthDay,
> whose definition doesn't make sense to me due to leap years:
> 
>    dateTime - <input type="datetime"> or "local-datetime"
>    time - <input type="time"> [1]
>    date - <input type="date"> [1]
>    gYearMonth - <input type="month">
>    gYear - <input type="number"> [1]
>    gDay - <input type="number"> [1]
>    gMonth - <select> [1]
>    boolean - <input type="checkbox">
>    base64Binary - <input type="file"> [2]
>    hexBinary - <input type="file"> [2]
>    float - <input type="number" step="any"> [3]
>    decimal - <input type="number">
>    integer, long, etc - <input type="number" min="..." max="...">
>    double - <input type="number" step="any"> [3]
>    anyURI - <input type="uri">
>    QName - <input type="uri"> <input type="text">
>    NOTATION - <input type="text">
>    string - <textarea>
>    normalizedString - <input>
>    token, etc - <input pattern="...">
> 
> [1] except for times with timezone specifiers
> [2] either that or <textarea>, I guess
> [3] except for NaN and INF.
> 
> Some of these can probably be made more accurate but the idea stands,
> namely that it is possible to map almost all the XML Schema types to Web
> Forms 2 right now.
> 
> 
> >> 3. The types in XML Schema are less readable than those in Web Forms 2.0
> >> and HTML4. For example, where HTML4 has the type "text", XML Schema has
> >> the type "normalizedString".
> >
> > Again I have no problem with having some legacy names, there are very
> > few anyway.
> 
> It's not only legacy names. IMHO "month" is a lot nicer than "gYearMonth",
> "uri" is nicer than "anyURI", and "number" is nicer than the 16 different
> kinds of number types in XML Schema.
> 
> 
> > Speaking of facets, WF2 only has inclusive min and max values, while XML
> > schema has maxInclusive, minExclusive as well as maxExclusive and
> > minExclusive. So there are conditions that can be declared in XML schema
> > but not in WF2. That is another reason why we should base WF2 on XML
> > schema datatype. It is a standard that was discussed for a long time and
> > it is less likely that they would miss something.
> 
> IMHO XML Schema missed usability.
> 
> The lack of exclusive minimums and maximums was intentional. Adding
> support for it at the markup level gains you very little and complicates
> the language. Same with things like "minlength", which are easily handled
> by the pattern="" attribute and don't need their own.
> 
> XML Schema also allows facets on many more types than makes sense, for
> example allowing a minimum and maximum length to be specified on numbers
> at the same time as minimum and maximum values.
> 
> Basically while XML Schema Part 2 might be a good type library for
> describing the types of attributes in XML languages, I do not believe it
> makes for a particularly good type library for Web applications and Web
> forms. Trying to make Web Forms 2 into somesort of hybrid HTML/XMLSchema
> superset would, IMHO, only make the resulting language ugly and harder for
> authors to use.
> 
> Also, it is worth bearing in mind that most HTML authors have never heard
> of XML Schema, let alone have any sort of familiarity with it. I doubt
> this is going to change in the near future.
> 
> 
> 
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>