OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] Removing ds elements from schema (was: OpenID Delegating relationship in XRD)


On Sep 8, 2009, at 9:46 AM, John Bradley wrote:

> I can live without the extension wrapper if we have a better way.
>
> I think recommending having the signature at the top for streaming  
> applications is sufficient.
>
> I don't think it makes any real difference to most parsers.
>
> The best way to limit it to one is the question.

Well, we would still have the XRD Signature section in the core spec,  
so we could state that there can be only one signature.  We wouldn't  
be enforcing it at the schema level, but I think that's okay.  We're  
already placing a number of restrictions on the Signature itself  
(specifically, reference and transformation) that weren't schema- 
enforced, so I don't see adding cardinality to that list as being a  
huge deal.  It's not as clean as one might like, but doable.

-will


> John B.
> On 2009-09-08, at 12:19 PM, Scott Cantor wrote:
>
>> Will Norris wrote on 2009-09-08:
>>> 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).
>>
>> Sorry I didn't think of it originally. I imagine it wouldn't be all  
>> that
>> hard to get one written based on the original one.
>>
>>> 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?
>>
>> It's not only that, it's also limiting the number to one. While it  
>> sometimes
>> comes up to support multiple signatures, that's somewhat complex in  
>> practice
>> (because of signature ordering).
>>
>>> 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?
>>
>> It's for streaming implementations.
>>
>>> I'm fairly certain the Java version of
>>> XML-Tooling does not.  How about the C version?
>>
>> We're exclusively DOM-based, so we don't care.
>>
>>> We could always
>>> recommend that XRD providers place the Signature element higher up  
>>> in
>>> the document.
>>
>> True.
>>
>> -- 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
>>
>
>
> ---------------------------------------------------------------------
> 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]