- From: Scott Cantor <cantor.2@osu.edu>
- Date: Wed, 20 Jan 2010 18:31:46 -0500
- To: "'MURATA Makoto \(FAMILY Given\)'" <eb2m-mrt@asahi-net.or.jp>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>
MURATA Makoto (FAMILY Given) wrote on 2010-01-20: > So, do some W3C specifications specify other algorithms that have > particular values of the Algorithm attribute and particular content > models? There are multiple places in XML Encryption itself that all reuse the same EncryptedData/EncryptedKey elements (again, depending on context) and the various algorithms defined to do different things would all be the authority on what they define there. There may be other specifications at W3C and elsewhere that profile additional algorithms, certainly, but I have no specific knowledge of them. The same issues apply to all the extension points in the Signature specification. > ##any or ##other with laxed validation can only be mimicked by > explicitly enumerating what has to be validated. (Note that > any-containing-xmldsig11-properties.rnc allows property elements > only as children of SignatureProperty elements.) That doesn't seem possible in general (in the sense that both ##any and ##other mean an infinite set of content options). You could create something specific to a problem domain, but not a general expression of what the XSD means. > But you do not have to enumerate what has to be skipped; you can > rely on wild cards such as > > anyForeignElement = element * - ds:* { > mixed { anyAttribute*, anyForeignElement* } } I suppose that suggests you're better off with that approach. -- Scott
Received on Wednesday, 20 January 2010 23:32:18 UTC