Re: Proposal: processing-instructions normalization feature for Document

If SOAP forbids them, then IMO, the proper action when you find them 
during normal SOAP processing is to raise an error, not remove them. 
 Otherwise they may still occur in the exchange with people thinking 
they are being properly processed.  It is not clear to me whether this 
non-infoset-inspired mode should be directly supported by DOM, but I 
think it could be supported by a custom parser option.  There are a 
number of other legal XML constructs forbidden by SOAP that should raise 
an exception if received.

I guess there might be a use case if you had an application that was 
putting them in (not parsing them in) or parsing them in from a non-SOAP 
source and you wanted it to work in SOAP.  It is not clear to me whether 
the application in many cases does not need to examine the PIs as they 
are removed.  Unlike CDATASections changing to text, or expansion of 
entity references, the logical information presented by a document is 
changed as a result of this operation.

Ray Whitmer
rayw@netscape.com

Elliotte Rusty Harold wrote:

>I'd like to propose an additional normalization feature to remove
>processing instructions from the document. The syntax would be modeled
>after the comments feature and be roughly as follows: 
>
>"processing-instructions"
>
>    true
>        [required] (default)
>    Keep Processing instruction nodes in the document.
>    false
>        [required]
>    Discard Processing instruction nodes in the Document.
>
>This could be useful in many cases where programmer 
>know they aren't going to consider processing instructions.
>For example, SOAP explicitly forbids them. Imagine I have
>an existing document, parsed or built from some source I 
>don't control and I want to copy its root element into a
>SOAP request or response. It would be 
>convenient to throw away processing instructions 
>in one normalizeDocument() call rather than having 
>to walk the tree to get rid of them. 
>

Received on Wednesday, 23 January 2002 14:27:23 UTC