Removing ds elements from schema (was: OpenID Delegating relationship in XRD)

[Will Norris <will@willnorris.com>]

I'm actually really interested in pursuing this a bit more as well.   
It would allow us to use the original content model we had, but in a  
way that works with XSD.  Interestingly, if we don't include the ds:*  
elements as part of the XRD schema, it would solve the problem we had  
with RelaxNG since there is no longer a schema dependence on XML  
DSig.  (Not that I'm necessarily advocating a switch back to RelaxNG  
at this point).

I'm curious to hear from John and Nat on this as well, since I recall  
them both being vocal about really liking the <Extensions> element  
which contains all extended elements.  It's worth noting, that even  
though <Extensions> provided a nice wrapper for extended elements, we  
still have extended attributes all over the place, so how much does  
that wrapper element really buy you as far as processing is concerned?

The other big question is the placement of ds:Signature.  I completely  
understand Scott's argument for placing it higher up in the document.   
This change we're discussing would mean that the Signature could now  
appear anywhere in the document.  Scott, how much of a concern is this  
really?  The idea of placing it higher is so that XML processors would  
know early on if they needed to be doing canonicalization.  How many  
processors actually alter their behavior in the presence of the  
Signature element in this way?  I'm fairly certain the Java version of  
XML-Tooling does not.  How about the C version?  We could always  
recommend that XRD providers place the Signature element higher up in  
the document.

thoughts from others?  If we're going to go down this route, I need to  
go ahead and start moving language around for working draft 07.

-will


On Sep 6, 2009, at 9:29 AM, Scott Cantor wrote:

> Drummond Reed wrote on 2009-09-04:
>> So if we can solve the problem by not explicitly listing the
>> non-XRD-namespace elements we use for sigs (ds:KeyInfo and
>> ds:Signature), but instead treating them as "formal extensions", I
>> really like that solution.
>
> It's not as awkward with KeyInfo as it is with Signature, frankly. I  
> would
> argue that top-level XRD extensions aren't as common, so I don't  
> know how
> important it is to do it there, but I suppose you could.
>
> One consequence is that the Signature wouldn't be in a predictable  
> location,
> so I guess that's why I wouldn't be as enthused about it there.
>
>> If we did that, how specifically would you suggest going about  
>> documenting
>> the use of elements from the ds: namespace in the spec. Just  
>> referencing
>> them in the Signature Processing section?
>
> I think you'd leave them documented in the text the same way, just  
> not list
> them in the schema.
>
> Alternatively, in the case of KeyInfo, if you look at the text now,  
> there's
> absolutely nothing in the spec that really says what to do with it.  
> I could
> make the argument that it doesn't even have to be mentioned here.
>
> -- Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>