You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Ray Grimmond <ra...@qwan.com> on 2002/08/11 08:11:59 UTC
Final Methods in DOMNormalizer.java
I want to use the same XMLDocumentHandler implementation in a number of places in both the parser pipeline as a filter ,
as a parser subclass, and also being driven by a serialize of the DOM Tree.
Using version 2.0.2 , I used the DOMNormalizer class to walk the dom by extending an XMLDocumentHandler implementation and
implementing Revalidation Handler
and by subclassing DOMNormalizer as follows
public class DNValidationHandler extends MyXMLDocumentHandler implements org.apache.xerces.impl.RevalidationHandler
{
public void setCurrentNode(Node node){
myCurrentNode = node; // myCurrentNode defined in MyXMLDocumentHandler
}
}
public class DOMNormalizerSubclass extends org.apache.xerces.dom.DOMNormalizer {
protected org.w3c.dom.Node normalizeNode(org.w3c.dom.Node node) {
validator.setCurrentNode(node);
}
protected void setValidationHandler(org.apache.xerces.impl.RevalidationHandler validator) {
this.validator = (DNValidationHandler) validator;
super.setValidationHandler(validator);
}
}
I know this is a rather unorthodox way of using the DOMNormalizer code but we do not want to use multiple DOM Serializers.
I dont want to use the org.xml.serialize package to serialize as there is no support for XMLDocumentHandler...
We need a way to serialize the DOMTree through XMLDocumentHandler and pass-through the current node in the tree, either as a
variable or as an augmentation.
Although not intended for its original purpose, it works like a charm, making all DOMNormalizer methods as protected FINAL
as in the latest CVS Version 1.7 will put a stop to this.
Please can you explain the reasons for changing these methods to FINAL ??
Do you really need to do this ???
Maybe an alternative is to factor out the Normalizer code (also non DOM-L3)
so that it can be used for other general serialization purposes (using XMLDocumentHandler) as well as for Re-validation.
Bottom Line - need to serialize DOM via XMLDocumentHandler.
Thanks
Ray Grimmond
ray@qwan.com
Re: Final Methods in DOMNormalizer.java
Posted by Ray Grimmond <ra...@qwan.com>.
Elena
>To avoid later complains from users about changes in functionality, I
>prefer keeping this code protected and final.
I understand your concern, if I use code from draft specs, and they change, I track the
code changes and dont complain. Will you change them back to public once L3 becomes a
recommendation.
Also you had serialization (org.xml.serialize) before L3 (see my comments regarding
a serialization core, that can be wrappered by L3 and non-L3 code)
>Do you need support to all the functionality offered by
>normalizeDocument, i.e. namespace fixup, support for different features
>(infoset, comments, entities, etc), attribute value normalization, or
>need to traverse the tree and serialize it via XMLDocumentHandler?
Both, we are building XML editors, which means that infosets, comments, entities,
attribute value normalization, plus order-of-attributes, whitespace-in-tags and all that
other lovely stuff that would be candidates to use and store as augmentations.
>If you only need the latest, I suggest you prototype a component that
>allows to serialize DOM via XMLDocumentHandler and contribute the code
>to Xerces.
I would assume over the long term that you would dump org.xml.serialize in favour
of using a new serializer supporting XMLDocumentHandler calls driven from or
centralized around normalizeDocument() and DOMWriter.
Is this in your plans for 2.1 and beyond ??
It doesnt make sense to have XNI on the load side, but not on the save side !!
It makes the whole XNI design rather limiting
I can build a custom lexer to handle say attribute-order , or create a
synthetic infoset on the load side using XNI, augment the DOM, but cant do
anything about it on the save side !!
Ray Grimmond
ray@qwan.com
Elena Litani wrote:
> Hi Ray,
>
> I am forwarding this message to the xerces-j-dev list.
>
> The DOMNormalizer class should have been *protected* from the start,
> since its primary reason is to provide implementation to
> normalizeDocument() function defined in the DOM Level 3 [1]. Given that
> the DOM Level 3 is at the stage of Working Draft, which represents work
> in progress and thus may be updated, I am concerned that some
> implementation, like yours, may choose to use this code not realizing
> that the DOMNormalizer code may change to reflect changes that could be
> introduced to the normalizeDocument() description.
> To avoid later complains from users about changes in functionality, I
> prefer keeping this code protected and final.
>
> Ray Grimmond wrote:
> > Please can you explain the reasons for changing these methods to
> > FINAL ??
>
> Performance (plus the above concerns).
>
> > Bottom Line - need to serialize DOM via XMLDocumentHandler.
>
> Do you need support to all the functionality offered by
> normalizeDocument, i.e. namespace fixup, support for different features
> (infoset, comments, entities, etc), attribute value normalization, or
> need to traverse the tree and serialize it via XMLDocumentHandler?
>
> If you only need the latest, I suggest you prototype a component that
> allows to serialize DOM via XMLDocumentHandler and contribute the code
> to Xerces.
>
> [1]
> http://www.w3.org/TR/2002/WD-DOM-Level-3-Core-20020409/core.html#Document3-normalizeDocument
>
> Thank you,
> --
> Elena Litani / IBM Toronto
>
> Ray Grimmond wrote:
> >
> >
> > I want to use the same XMLDocumentHandler implementation in a number
> > of places in both the parser pipeline as a filter , as a parser
> > subclass, and also being driven by a serialize of the DOM Tree.
> >
> > Using version 2.0.2 , I used the DOMNormalizer class to walk the dom
> > by extending an XMLDocumentHandler implementation and implementing
> > Revalidation Handler
> > and by subclassing DOMNormalizer as follows
> >
> > public class DNValidationHandler extends MyXMLDocumentHandler
> > implements org.apache.xerces.impl.RevalidationHandler
> > {
> > public void setCurrentNode(Node node){
> > myCurrentNode = node; // myCurrentNode defined
> > in MyXMLDocumentHandler
> > }
> > }
> >
> > public class DOMNormalizerSubclass extends
> > org.apache.xerces.dom.DOMNormalizer {
> >
> >
> > protected org.w3c.dom.Node normalizeNode(org.w3c.dom.Node
> > node) {
> > validator.setCurrentNode(node);
> > }
> >
> > protected void
> > setValidationHandler(org.apache.xerces.impl.RevalidationHandler
> > validator) {
> > this.validator = (DNValidationHandler) validator;
> > super.setValidationHandler(validator);
> > }
> >
> > }
> >
> > I know this is a rather unorthodox way of using the DOMNormalizer code
> > but we do not want to use multiple DOM Serializers.
> >
> > I dont want to use the org.xml.serialize package to serialize as
> > there is no support for XMLDocumentHandler...
> >
> > We need a way to serialize the DOMTree through XMLDocumentHandler and
> > pass-through the current node in the tree, either as a variable or as
> > an augmentation.
> >
> > Although not intended for its original purpose, it works like a
> > charm, making all DOMNormalizer methods as protected FINAL as in the
> > latest CVS Version 1.7 will put a stop to this.
> >
> > Please can you explain the reasons for changing these methods to
> > FINAL ??
> > Do you really need to do this ???
> > Maybe an alternative is to factor out the Normalizer code (also non
> > DOM-L3)
> > so that it can be used for other general serialization purposes
> > (using XMLDocumentHandler) as well as for Re-validation.
> >
> > Bottom Line - need to serialize DOM via XMLDocumentHandler.
> >
> > Thanks
> >
> >
> > Ray Grimmond
> > ray@qwan.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Final Methods in DOMNormalizer.java
Posted by Elena Litani <el...@ca.ibm.com>.
Hi Ray,
I am forwarding this message to the xerces-j-dev list.
The DOMNormalizer class should have been *protected* from the start,
since its primary reason is to provide implementation to
normalizeDocument() function defined in the DOM Level 3 [1]. Given that
the DOM Level 3 is at the stage of Working Draft, which represents work
in progress and thus may be updated, I am concerned that some
implementation, like yours, may choose to use this code not realizing
that the DOMNormalizer code may change to reflect changes that could be
introduced to the normalizeDocument() description.
To avoid later complains from users about changes in functionality, I
prefer keeping this code protected and final.
Ray Grimmond wrote:
> Please can you explain the reasons for changing these methods to
> FINAL ??
Performance (plus the above concerns).
> Bottom Line - need to serialize DOM via XMLDocumentHandler.
Do you need support to all the functionality offered by
normalizeDocument, i.e. namespace fixup, support for different features
(infoset, comments, entities, etc), attribute value normalization, or
need to traverse the tree and serialize it via XMLDocumentHandler?
If you only need the latest, I suggest you prototype a component that
allows to serialize DOM via XMLDocumentHandler and contribute the code
to Xerces.
[1]
http://www.w3.org/TR/2002/WD-DOM-Level-3-Core-20020409/core.html#Document3-normalizeDocument
Thank you,
--
Elena Litani / IBM Toronto
Ray Grimmond wrote:
>
>
> I want to use the same XMLDocumentHandler implementation in a number
> of places in both the parser pipeline as a filter , as a parser
> subclass, and also being driven by a serialize of the DOM Tree.
>
> Using version 2.0.2 , I used the DOMNormalizer class to walk the dom
> by extending an XMLDocumentHandler implementation and implementing
> Revalidation Handler
> and by subclassing DOMNormalizer as follows
>
> public class DNValidationHandler extends MyXMLDocumentHandler
> implements org.apache.xerces.impl.RevalidationHandler
> {
> public void setCurrentNode(Node node){
> myCurrentNode = node; // myCurrentNode defined
> in MyXMLDocumentHandler
> }
> }
>
> public class DOMNormalizerSubclass extends
> org.apache.xerces.dom.DOMNormalizer {
>
>
> protected org.w3c.dom.Node normalizeNode(org.w3c.dom.Node
> node) {
> validator.setCurrentNode(node);
> }
>
> protected void
> setValidationHandler(org.apache.xerces.impl.RevalidationHandler
> validator) {
> this.validator = (DNValidationHandler) validator;
> super.setValidationHandler(validator);
> }
>
> }
>
> I know this is a rather unorthodox way of using the DOMNormalizer code
> but we do not want to use multiple DOM Serializers.
>
> I dont want to use the org.xml.serialize package to serialize as
> there is no support for XMLDocumentHandler...
>
> We need a way to serialize the DOMTree through XMLDocumentHandler and
> pass-through the current node in the tree, either as a variable or as
> an augmentation.
>
> Although not intended for its original purpose, it works like a
> charm, making all DOMNormalizer methods as protected FINAL as in the
> latest CVS Version 1.7 will put a stop to this.
>
> Please can you explain the reasons for changing these methods to
> FINAL ??
> Do you really need to do this ???
> Maybe an alternative is to factor out the Normalizer code (also non
> DOM-L3)
> so that it can be used for other general serialization purposes
> (using XMLDocumentHandler) as well as for Re-validation.
>
> Bottom Line - need to serialize DOM via XMLDocumentHandler.
>
> Thanks
>
>
> Ray Grimmond
> ray@qwan.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Final Methods in DOMNormalizer.java
Posted by Elena Litani <el...@ca.ibm.com>.
Hi Ray,
I am forwarding this message to the xerces-j-dev list.
The DOMNormalizer class should have been *protected* from the start,
since its primary reason is to provide implementation to
normalizeDocument() function defined in the DOM Level 3 [1]. Given that
the DOM Level 3 is at the stage of Working Draft, which represents work
in progress and thus may be updated, I am concerned that some
implementation, like yours, may choose to use this code not realizing
that the DOMNormalizer code may change to reflect changes that could be
introduced to the normalizeDocument() description.
To avoid later complains from users about changes in functionality, I
prefer keeping this code protected and final.
Ray Grimmond wrote:
> Please can you explain the reasons for changing these methods to
> FINAL ??
Performance (plus the above concerns).
> Bottom Line - need to serialize DOM via XMLDocumentHandler.
Do you need support to all the functionality offered by
normalizeDocument, i.e. namespace fixup, support for different features
(infoset, comments, entities, etc), attribute value normalization, or
need to traverse the tree and serialize it via XMLDocumentHandler?
If you only need the latest, I suggest you prototype a component that
allows to serialize DOM via XMLDocumentHandler and contribute the code
to Xerces.
[1]
http://www.w3.org/TR/2002/WD-DOM-Level-3-Core-20020409/core.html#Document3-normalizeDocument
Thank you,
--
Elena Litani / IBM Toronto
Ray Grimmond wrote:
>
>
> I want to use the same XMLDocumentHandler implementation in a number
> of places in both the parser pipeline as a filter , as a parser
> subclass, and also being driven by a serialize of the DOM Tree.
>
> Using version 2.0.2 , I used the DOMNormalizer class to walk the dom
> by extending an XMLDocumentHandler implementation and implementing
> Revalidation Handler
> and by subclassing DOMNormalizer as follows
>
> public class DNValidationHandler extends MyXMLDocumentHandler
> implements org.apache.xerces.impl.RevalidationHandler
> {
> public void setCurrentNode(Node node){
> myCurrentNode = node; // myCurrentNode defined
> in MyXMLDocumentHandler
> }
> }
>
> public class DOMNormalizerSubclass extends
> org.apache.xerces.dom.DOMNormalizer {
>
>
> protected org.w3c.dom.Node normalizeNode(org.w3c.dom.Node
> node) {
> validator.setCurrentNode(node);
> }
>
> protected void
> setValidationHandler(org.apache.xerces.impl.RevalidationHandler
> validator) {
> this.validator = (DNValidationHandler) validator;
> super.setValidationHandler(validator);
> }
>
> }
>
> I know this is a rather unorthodox way of using the DOMNormalizer code
> but we do not want to use multiple DOM Serializers.
>
> I dont want to use the org.xml.serialize package to serialize as
> there is no support for XMLDocumentHandler...
>
> We need a way to serialize the DOMTree through XMLDocumentHandler and
> pass-through the current node in the tree, either as a variable or as
> an augmentation.
>
> Although not intended for its original purpose, it works like a
> charm, making all DOMNormalizer methods as protected FINAL as in the
> latest CVS Version 1.7 will put a stop to this.
>
> Please can you explain the reasons for changing these methods to
> FINAL ??
> Do you really need to do this ???
> Maybe an alternative is to factor out the Normalizer code (also non
> DOM-L3)
> so that it can be used for other general serialization purposes
> (using XMLDocumentHandler) as well as for Re-validation.
>
> Bottom Line - need to serialize DOM via XMLDocumentHandler.
>
> Thanks
>
>
> Ray Grimmond
> ray@qwan.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org