Re: Decryption Transform processing question

>> >> C14n isn't necessarily right because it will not output entity
>> >> declarations. I was hoping to punt to the serialized form that X was
>> >> constructed from; but, of course, there may not have been an original
>> >> serialized form.
>> >>
>> >> Actually, that's a problem: Our defined wrapping (emit entity
>> >> declarations) cannot be implemented on DOM; DOM does not expose that
>> >> information.
>> >
>> >As an aside, I agree C14N won't emit the entity declarations, but if
you
>> >have a DOM tree parsed from an instance that did, the declaration and
the
>> >content of the external entity should both be available to you -- I
think.
>> >Philippe?
>>
>>
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-527DCFF2

>>
>>   Interface Entity
>>
>>   This interface represents an entity, either parsed or unparsed, in an
>>   XML document. Note that this models the entity itself not the entity
>>   declaration. Entity declaration modeling has been left for a later
Level
>>   of the DOM specification.
>>
>> I could be misinterpreting the text; I'm not sure. DOM level
>> 3 has the same language in it. The raw DocumentType will be
>> available, but I'd rather not peer into it.
>
>I entirely forgot about this sentence regarding entities vs entity
>declarations. My guess here is that the entity node do represent its
>entity declaration to some extent. The DOM will not expose all entity
>declarations but only if some of them are overrided. Given that, entity
>nodes are not ordered, unlike entity declarations but given that the
>missing declarations were overridden, is it still important to have
>them?

I think so, too, and it should be possible to reconstruct entity
declarations.  Actually, our DOM-based implementation does so by referring
to Entity nodes obtained from a DocumentType node.  I have not tested any
parsers except Xerces2, though.  Anyway, because we specify the processing
rule to serialize data according to XML and XML allows entity references to
be included, I don't think that we should restrict it unnecessarily.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com

Received on Wednesday, 17 July 2002 02:13:23 UTC