W3C home > Mailing lists > Public > public-xsd-databinding@w3.org > January 2006

Re: ISSUE-5: Open Enumerated Type

From: Ed Day <edday@obj-sys.com>
Date: Thu, 26 Jan 2006 11:30:42 -0500
Message-ID: <01ac01c62295$da5346c0$4800000a@objsys1>
To: "Pete Cordell" <petexmldev@tech-know-ware.com>, "Databinding WG" <public-xsd-databinding@w3.org>

Well, some of us do still use ASN.1..

But this reminds me of another binding issue.  There is (apparently) no
equivalent in XSD to the ASN.1 NULL type.  The result is that users have to
make up their own and the results are often inconsistent.  For example, in
the CSTA specs, we see the following type definition:

  <xsd:annotation>
    <xsd:documentation>replacement for ASN.1 NULL type and helper type for
representation of the ASN.1 BIT STRING type</xsd:documentation>
  </xsd:annotation>
  <xsd:complexType name="Empty"/>

In XMPP, there is:

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

It would be nice if a best practice schema pattern for representing empty
data could be published.

Regards,

Ed Day
Objective Systems, Inc.
http://www.obj-sys.com

----- Original Message -----
From: "Pete Cordell" <petexmldev@tech-know-ware.com>
To: "Databinding WG" <public-xsd-databinding@w3.org>
Sent: Thursday, January 26, 2006 10:48 AM
Subject: Re: ISSUE-5: Open Enumerated Type


>
> Just for completeness...
>
> In the days when we used ASN.1, for some reason we never used enumerated
> types even though the language supported it.  Instead we used a choice of
> NULL options.  I don't know why this was as I joined the effort after this
> precedent had been set.  But it does raise the possibility of using a
> similar approach for XSD.  Something like:
>
> <element name='options'>
>     <choice>
>         <element name='option1' type='t:empty'/>
>         <element name='option2' type='t:empty'>
>         <!-- Favorite extensibility mechanism -->
>         <any namespace='##other'>
>     </choice>
> </element>
>
> To be represented something like:
>
>     <options><option2/><options>
>
> Actually, more than once this approach gave us a get out when we needed to
> add more data to the option than just the name!
>
> If this is deemed not too wacky, it could be presented as one possible
> alternative to the extensible enumeration.
>
> Regards,
>
> Pete.
> --
> =============================================
> Pete Cordell
> Tech-Know-Ware Ltd
>                          for XML to C++ data binding visit
>                          http://www.tech-know-ware.com/lmx
>                          (or http://www.xml2cpp.com)
> =============================================
>
> ----- Original Message -----
> From: "Databinding Issue Tracker" <dean+cgi@w3.org>
> To: <public-xsd-databinding@w3.org>
> Sent: Monday, January 09, 2006 11:32 PM
> Subject: ISSUE-5: Open Enumerated Type
>
>
> >
> >
> > ISSUE-5: Open Enumerated Type
> >
> > http://www.w3.org/2005/06/tracker/databinding/issues/5
> >
> > Raised by: Paul Downey
> > On product: Basic
> >
> > Our input document includes an "Extensible Enumerated Type" pattern:
> >
> > http://www.w3.org/2005/07/xml-schema-patterns.html#Enumerated-Extensible
> >
> > As common a Schema pattern as this may be, experience with current
> > databinding
> > tools means its use is unlikely to give users a good experience with
> > databinding
> > tools. Does this pattern belong in Basic or Advanced patterns?
> >
> >
> >
> >
>
>
>
>
>
Received on Thursday, 26 January 2006 16:30:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:20:36 GMT