RE: KeyInfo

At 17:45 1/14/2001 -0800, Brian LaMacchia wrote:
>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?
>
>[bal] Because if I build a lightweight parser the knows I only care
>about <SPKIData> stuff, I can skip over everything between <PGPData> and
></PGPData>.  That is, when I place the new element MyPGPNS:foo under the
><PGPData> ... </PGPData> element I'm declaring a small piece of
>metadata, namely that MyPGPNS:foo is of the same class of data as other
>things in PGPData.

The nice thing about schema is that it allows you to declare this 
relationship explicitly. In this instance, you are proposing that we use the 
<ds:PGPData> as an element that is acting as an additional "typing" 
mechanism; in this case it does not require the presence of the schema, but 
this semantic must also be expressed in natural lanugage in the spec and 
specially coded for.

>This is meaningless to parsers and schema validators.
>
>[bal] Why do you say this?  It can be parsed, it can be schema
>validated, and when I get the nod structure back from the parser and
>start analyzing for semantic content, I can semantically qualify the
>extension elements.

I mean their relationship is not automatably meaningful. Your proposal has 
to be handcode for (but it permits light parsers) my proposal lets this work 
be done by schema, but requires schema.

>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)?
>
>[bal] The same way you do this for any other extensible schema element?
>Why is this any different?

I believe ANY only permits "global elements" to be incorporated in, so if 
there is some schema out there that permits:
<root>
   <global>
     <local>

those local elements can't be incorporated in via ANY.

>--
>
><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.
>
>[bal] OK, so how do I extend KeyInfo then?  What you seem to be implying
>is that the W3C Schema religion does not allow extensible data
>structures at all!  That can't possibly be true, can it?  It Schema
>really so brain damanged that extensibility mechanisms must be put into
>string values?

I'm advocating that it be extended by creating a new type, that is a class 
of our own. (Actually, as we agreed to before, I'm not opposed to the above, 
I'm just not keen on it, what I'm opposed to is below...)

>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.
>
>[bal] I don't understand this.  Are you saying, "well, they can't
>redefine the schema for ds:PGPData so they're stuck."  But that schema
>allows an <any...> so they can plug in there?

If someone wants to take the construct above and create a new class out of 
that, they can't really since it's a "mule."

>--
><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.
>
>[bal] Why is this ambiguous?  You've defined two different tag types;
>there's no implied relationship between ds:PGPData and mypgp:PGPData
>because they're namespace qualified.

You're asserting that there is an implied "meta data typing" relationship. 
I'd rather this relationship be explicit and expressed in schema.

>--
>
><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!
>
>[bal] I'm not familiar with <extension...>, so how does that define
>where the new element goes in the already-defined PGPData?

It doesn't, it goes under KeyInfo. The application looks at the mypgp 
namespace, see's a schema, sees this is an extension of PGPData (for which 
it already knows how to deal with) plus a string. The schema or other data 
associated with the namespace might tell it how to deal with that string.

>defined here in the extension?  And won't I end up having to transport
>the new schema everywhere I transport the new KeyInfo blob?

It's at a URI, so it does require an association between a namespace and a 
targetSchema.

>And if I do this, any V1 code that isn't schema-aware will not be able to do
>anything with this element at all.

True.

>[bal] In summary, it sounds like what you want is a spec that requires
>schema-aware XML parsers in order to handle any extensions to the base
>data types defined in XMLDSIG.  I am not at all convinced that is a good
>thing for lightweight devices.  If it becomes impossible to use XMLDSIG
>in private-label operations without bundling in a whole bunch of schema
>stuff I fear we will drive off a whole boatload of potential customers.

This is correct, and I'm happy to go with the consensus now that the issue 
is clearly identified! <smile>


__
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:46:12 UTC