> Dirk Balfanz wrote on 2009-09-04:
> >> Keep in mind that we should optimize for the common case. If it's going
> to
> >> be common to put extensions inside Link, it may be simpler to just wrap
> >> KeyInfo in something and solve the ambiguity that way.
> >
> > This does seem weird. Shouldn't the fact that we're using a different
> > name space be enough of a hint that this is an extension?
>
> Scott Cantor wrote on 2009-09-04:
> If you want the gory details I can provide them, but no, it's not, not
> when
> all your content is optional and you already have a non-wildcard child
> element from another namespace explicitly defined in the schema.
>
> The other possible fixes are:
>
> - wrap the other child element into this namespace (KeyInfo in this case)
> - make the other child element a formal extension (not listing it
> explicitly
> in the schema)
>
> I hadn't proposed the latter before, but it is a possible fix.
Scott, this potentially is a really good fix. The problem with the
Extensions element is that implementers are already used to sticking their
extension elements directly in as children of <Link> (formerly <Service> in
XRDS). Plus just using namespace-qualified extension elements is natural in
XML.
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.
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?
=Drummond
