W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 2001

RE: X509 Schema Tweaks (Was: XML Signature schema implementation)

From: Gregor Karlinger <gregor.karlinger@iaik.at>
Date: Mon, 1 Oct 2001 09:59:24 +0200
To: "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: "XMLSigWG" <w3c-ietf-xmldsig@w3.org>, "Philip Hallam-Baker" <pbaker@verisign.com>
Message-ID: <LBEPJAONIMDADHFHAEAOMEDDCJAA.gregor.karlinger@iaik.at>
I agree with Phillip. Introducing a type for every element will
simplify the reuse of dsig elements. I do not think that its
looks ugly enough to justify avoidance of type definitions ;-)

Liebe Gruesse/Regards,
---------------------------------------------------------------
DI Gregor Karlinger
mailto:gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------


> -----Original Message-----
> From: w3c-ietf-xmldsig-request@w3.org
> [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Hallam-Baker,
> Phillip
> Sent: Thursday, September 27, 2001 11:32 PM
> To: 'reagle@w3.org'; Tom Gindin; Peter Tornberg
> Cc: xmldsig; bal@microsoft.com
> Subject: RE: X509 Schema Tweaks (Was: XML Signature schema
> implementation)
>
>
>
> If we are opening this up I would prefer to simply have a rule
> that we have
> a type declared for every element.
>
> It may look ugly in some folk's view, but the fault lies in XML
> schema. The
> distinction between elements and element types is unnecessary, especially
> since they invented abstract types. But they did wot they did.
>
> 		Phill
>
>
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
>
>
> > -----Original Message-----
> > From: Joseph Reagle [mailto:reagle@w3.org]
> > Sent: Thursday, September 27, 2001 5:18 PM
> > To: Tom Gindin; Peter Tornberg
> > Cc: xmldsig; bal@microsoft.com
> > Subject: X509 Schema Tweaks (Was: XML Signature schema implementation)
> >
> >
> > On Friday 21 September 2001 06:34 pm, Tom Gindin wrote:
> > >      By the way, all of the elements in this case except
> > for X509SKI are
> > > plausible candidates for reuse.  X509Certificate, X509CRL, and
> > > X509SubjectName are all more likely to be reused in another
> > spec than
> > > X509IssuerSerial.
> >
> > In that case, I think the tweaked schema would need to look
> > like [1]. This
> > wouldn't affect parser or schema validation performance I
> > don't think. It
> > does permit  people to borrow our natural language
> > specification of how
> > these things are encoded and such. However, it is rather
> > ugly, if someone
> > wants to re-use it, they could redefine/import them in a new
> > namespace, and
> > it divorces these element types from their context/meaning as
> > properties of
> > a single X509Data structure.
> >
> > These are all minor points, but given our late stage in the
> > game, I'd like
> > to hear more voices in support of this change...
> >
> >
> > [1]  Tweaked X509DataType
> > <complexType name="X509DataType">
> >    <sequence maxOccurs="unbounded">
> >       <choice>
> >          <element ref="ds:X509IssuerSerial"/>
> >          <element ref="ds:X509SKI"/>
> >          <element ref="ds:X509SubjectName"/>
> >          <element ref="ds:X509Certificate"/>
> >          <element ref="ds:X509CRL"/>
> >          <any namespace="##other" processContents="lax"/>
> >       </choice>
> >    </sequence>
> > </complexType>
> >
> > <element name="X509IssuerSerial" type="ds:X509IssuerSerialType"/>
> > <element name="X509SKI" type="base64Binary"/>
> > <element name="X509SubjectName" type="string"/>
> > <element name="X509Certificate" type="base64Binary"/>
> > <element name="X509CRL" type="base64Binary"/>
> >
> > <complexType name="X509IssuerSerialType">
> >    <sequence>
> >       <element name="X509IssuerName" type="string"/>
> >       <element name="X509SerialNumber" type="integer"/>
> >    </sequence>
> > </complexType>
> >
>
>
Received on Monday, 1 October 2001 03:59:12 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:14 GMT