Custom XML Types (Was: Decryption Transform processing question)

On Wednesday 29 May 2002 07:36 pm, merlin wrote:
> I would like to be able to indicate that certain custom Type
> URIs should be treated as XML. For example, I would like to
> be able to have <EncryptedData Type="&foo;PrivateKey" ... />
> to indicate that encrypted data are a PrivateKey element. I
> agree that this is just &enc;Element; however, the alternative
> type is more informative. For a proposed solution, see the
> attached (which is my suggested changes with another change).

1. I'm unclear about the prefix and URI thing in your proposal. I think an 
example would help.
2. Is this type the actual element type? If so, why not just encrypt its 
content instead of the element type name?
3. My preference is not to include more type attributes. My expectation is 
if there was a type such as &foo;PrivateKey somewhere there would be a 
specification (e.g., dereference it) that says "treat me just like 
&xenc;Element and also foo." This definitely applies if that "foo" (e.g., 
decompress the content of that element using gzip) is some 
normative/required behavior. I suspect in your scenario, this is not the 
case? All you want is the &xenc;Element behavior but the foo is useful but 
informational? 

For example, if that foo is normative, then the processing will fail 
because it doesn't know what to do with it. But if it's not, it'll still be 
processed as &xenc;Element and the "foo" is ignored?

Even we did go this route, that means we'd have
1. A normative Type attribute.
2. An ?informational? Other attribute. (Your XMLType element though I don't 
yet understand it.)
3. An informational MimeType attribute.

It's getting sort of hairy.

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Thursday, 30 May 2002 12:23:49 UTC