[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] OpenID Delegating relationship in XRD
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]