You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Sebastien Ponce <se...@cern.ch> on 2000/12/15 10:35:26 UTC

Re: How to do not expand extity references in attributes?

I've just run into the same problem and I found the same solution.
What I would suggest is to add a feature to xerces called expand-entity-ref
that would be used in this place to expand or not entities.

Sebastien

Rudolf Michalek wrote:

> I need to parse XML document and create DOM structure with
> unexpanded entities in attributes. It allows me write it back
> with unchanged state.
>
> I tried to find some clear solution but failed. I found only how to
> patch
> Xerces (1.2.2) to don't expand entities:
>   I comment some lines of code for recognizing entities
>   in class org.apache.xerces.framework.XMLDocumentScanner
>   inside method scanAttValue(...)
> It works fine, but it is very unclean solution.
>
> I hope that somebody will be able to advice me some better solution.


Re: How to do not expand extity references in attributes?

Posted by Petr Kuzel <Pe...@netbeans.com>.
Sebastien Ponce wrote:
> 
> I've just run into the same problem and I found the same solution.
> What I would suggest is to add a feature to xerces called expand-entity-ref
> that would be used in this place to expand or not entities.
> 
> Sebastien
> 
> Rudolf Michalek wrote:
> 
> > I need to parse XML document and create DOM structure with
> > unexpanded entities in attributes. It allows me write it back
> > with unchanged state.

  Hello,

  I have just posted a requirement that could solve this issue too.
  See subject Xerces_J_2 feature proposal.

  What's your opinion?
  Ccc

-- 
<address>
<a href="mailto:pkuzel@netbeans.com">Petr Kuzel</a>, Sun Microsystems
: <a href="http://www.sun.com/forte/ffj/ie/">Forte Tools</a>
: XML and <a href="http://jini.netbeans.org/">Jini</a> modules</address>

Re: How to do not expand extity references in attributes?

Posted by Sebastien Ponce <se...@cern.ch>.
> I think I understand why you're asking this but do you really realize
> the implications though? Everytime we add a feature we add some ifs into
> the code, which impacts the performance. I guess this one would only
> affect the code handling entity refs which may not be so bad. But this
> raises the general question of what Xerces is designed for.

I fully agree.

> There are two main categories of XML applications:
> 1) consuming applications - applications that extract data from an XML
> document and want the document as cooked as possible.
> 2) transforming applications - applications that perform some kind of
> modification to an XML document and would like to get the new document
> as identical as the original one as possible, apart from what is
> effectively changed.
>
> Clearly Xerces wasn't designed for the latter. It would require
> transmitting a lot more information than we currently do (like what type
> of quotes was used for an attribute, the order of the attributes,
> etc...) Of course, you may tell me "oh, I don't care about that", but
> I'm sure somebody else will. So, how do we decide what to support?
> I really don't know.

Even if xerces wasn't design for transforming applications, I think that the
parse + serialize operation should lead to a file similar to the original one,
which is not the case at this time, since the entity are expanded in the
operation. Actually, I should rather say that the serialize + parse operation
should lead to a tree similar to the original one, which supposes that entities
are not expanded but allows to remove spaces and such meaningless nodes.

Another point is that xerces, at this time, does not create entityref nodes for
entity references inside attributes (see DOMParser, line ~1335). I told Andy
that I would try to implement that when I have time and I'm still trying to find
some. This would at least make a difference between attribtutes using entity
references and others.

Sebastien Ponce


Re: How to do not expand extity references in attributes?

Posted by Arnaud Le Hors <le...@us.ibm.com>.
Sebastien Ponce wrote:
> 
> I've just run into the same problem and I found the same solution.
> What I would suggest is to add a feature to xerces called expand-entity-ref
> that would be used in this place to expand or not entities.
> 
> Sebastien
> 
> Rudolf Michalek wrote:
> 
> > I need to parse XML document and create DOM structure with
> > unexpanded entities in attributes. It allows me write it back
> > with unchanged state.
> >
> > I tried to find some clear solution but failed. I found only how to
> > patch
> > Xerces (1.2.2) to don't expand entities:
> >   I comment some lines of code for recognizing entities
> >   in class org.apache.xerces.framework.XMLDocumentScanner
> >   inside method scanAttValue(...)
> > It works fine, but it is very unclean solution.
> >
> > I hope that somebody will be able to advice me some better solution.

I think I understand why you're asking this but do you really realize
the implications though? Everytime we add a feature we add some ifs into
the code, which impacts the performance. I guess this one would only
affect the code handling entity refs which may not be so bad. But this
raises the general question of what Xerces is designed for.

There are two main categories of XML applications:
1) consuming applications - applications that extract data from an XML
document and want the document as cooked as possible.
2) transforming applications - applications that perform some kind of
modification to an XML document and would like to get the new document
as identical as the original one as possible, apart from what is
effectively changed.

Clearly Xerces wasn't designed for the latter. It would require
transmitting a lot more information than we currently do (like what type
of quotes was used for an attribute, the order of the attributes,
etc...) Of course, you may tell me "oh, I don't care about that", but
I'm sure somebody else will. So, how do we decide what to support?
I really don't know.
-- 
Arnaud  Le Hors - IBM Cupertino, XML Technology Group