[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Removing ds elements from schema
Is it correct to understand that <Extensions> element which are
still in WD06 are going to be removed in WD07? =nat Joseph Anthony Pasquale Holsten wrote: +1 to removal I do wish this justified using RELAX NG again. I so dislike bringing another XSD into the world. But I don't have time to do it, so I defer to Scott and Will. On Sep 8, 2009, at 1:51 PM, Will Norris wrote:Given that many, if not most, of the people who were in favor of the <Extensions> element have expressed favor toward this approach, I'm going to go ahead and start reworking the text. I'm certainly not considering this matter closed, but I don't want to delay getting started on the work for too long. So if people have further comments the please, by all means, add them. -will On Sep 8, 2009, at 10:43 AM, Eran Hammer-Lahav wrote:I completely agree. EHL-----Original Message----- From: Will Norris [mailto:will@willnorris.com] Sent: Tuesday, September 08, 2009 10:00 AM To: XRI TC Subject: Re: [xri] Removing ds elements from schema (was: OpenID Delegating relationship in XRD) On Sep 8, 2009, at 9:52 AM, Will Norris wrote: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.Of course now that I think about it, nothing prevents people from having multiple signatures using the current schema. We state only that extension elements must not use the XRD namespace, but say nothing of the DSig namespace. I'm thinking that the farthest we should go (if at all) is to *recommend* that a only a single signature be used, because many (most?) consumers will not be able to properly handle multiple signatures. The common signing use case is going to be a single signature, so hopefully we won't have to worry about this too much. And if someone is feeling industrious and wants to add multiple signatures, I'm not sure that we should necessarily try and stop that. They just need to be aware of the potential complications involved. -will --------------------------------------------------------------------- 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--------------------------------------------------------------------- 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]