RE: KeyInfo

At 09:30 1/12/2001 -0800, Brian LaMacchia wrote:
>This is the issue on which I am confused: why do you believe we have to
>prohibit X509Data/PGPData/SPKIData elements that contain only children from
>an external namespace?  Thinking about it more, I really don't see why we
>should ban structures like this:
>
>         <PGPData>
>            <MyPGPNS:foo>barbaz</MyPGPNS:foo>
>         </PGPData>

Because I want to strongly discourage this! If someone is going to have 
something from MyPGPNS, what's the benefit/meaning of having this included 
in our namespace qualified PGP element? This is meaningless to parsers and 
schema validators. How would they define their own schema such that children 
are going to get used from their namespace in our context (and away from 
their own parent)? This approach of ANY (trying to hack an extensibility 
mechanism when schema provides a very nice one) pretty much destroys schema 
classes and the meaning between the elements. It also makes it unlikely that 
if a useful construct is built, it will be useable to others.

--

<ds:PGPData>
   <ds:PGPKeyID>foo</ds:PGPKeyID>
</ds:PGPData>

Is well defined and can be strictly schema validated, and used as a class 
elsewhere.

--

<ds:PGPData>
   <ds:PGPKeyID>foo</ds:PGPKeyID>
   <mypgp:GreatElement>bat</mypgp:GreatElement>
</ds:PGPData>

Is confusing. What's the relationship between PGPData's and GreatExtension? 
GreatExtension had a parent, but now it's just been plucked from it's schema 
and stuck in PGPData, maybe in its schema, it was never intended to be used 
alone like this (because of the definition of its parent), but now it is! 
You've advocated the need for this for extension capabilities in the short 
term because schema isn't a REC yet, and I've budged. However, any other 
KeyStructure standards that are written expecting to be used like this I 
would object to.

Plus, if the above instance ended up being a useful structure, others can't 
extend it themselves as a class. It's a mule (donkey+horse) and unable to go 
further.

--
<ds:PGPData>
   <mypgp:PGPData>
     <mypgp:BetterPGPKeyID>foo</mypgp:BetterPGPKeyID>
     <mypgp:GreatElement>foo</mypgp:GreatElement>
   </mypgp:PGPData>
</ds:PGPData>

Has the unique characteristic of being ambiguous (relationship between the 
two PGPData's) and when disambiguated (requires human) redundant! It should 
be under KeyInfo.

--

<mypgp:PGPData>
   <mypgp:PGPKeyID>foo</mypgp:PGPKeyID>
   <mypgp:GreatElement>foo</mypgp:GreatElement>
</mypgp:PGPData>

with the schema declaration:

<complexType name="PGPData">
  <complexContent>
   <extension base="ds:PGPData">
    <sequence>
     <element name="GreatExtension" type="string"/>
    </sequence>
   </extension>
  </complexContent>
</complexType>

Is clean! A parser knowns that any instance of mypgp:PGPData is just like 
ds:PGPData but with a new element!

>but could we just do that with a minOccurs="1" on a sequence, like this:
>
>    <complexType name="PGPDataType">
>      <choice>
>        <sequence minOccurs="1">
>          <element name="PGPKeyID" type="string" minOccurs="0"/>
>          <element name="PGPKeyPacket" type="ds:CryptoBinary" minOccurs="0"/>
>
>          <any namespace="##other" processContents="lax" minOccurs="0"
>           maxOccurs="unbounded"/>
>        </sequence>
>      </choice>
>    </complexType>
>
>Is that allowed?  This would also work nicely for X509Data & SPKIData.

My main concern in an editorial capacity has been to clarify any ambiguities 
in the spec. In discovering/understanding your need for this extension hack, 
we've moved towards deploying the ANYs consistently in the limited context 
of complementing/extending elements from the dsig namespace. BUT I'm opposed 
to going so far as to allow them to sit alone as you suggest. If we go 
there, I want to take it back to the WG and the schema reviewers. In fact, 
we've made enough tweaks we need to post this to the WG regardless -- and 
I'm thinking it might be useful to move this thread to the WG (including 
this email, if you'd like to forward your first one?)


__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Tuesday, 16 January 2001 18:23:43 UTC