Many haven't been confirmed. Some others wouldn't be
reachable through an LSSerializer. How that compares to the Xalan
version when it's used as an LSSerializer I'm not sure.
> Thanks again.
>
> On 6/21/10 1:57 PM, Michael Glavassevich wrote:
> > If
potential problem for one or more known problems.
It's been awhile since I've spent any time looking at either serializer.
For reference there are 26 JIRA issues [1] still open against the Xerces
serializer. Many haven't been confirmed. Some others wouldn't be reachable
through
1:57 PM, Michael Glavassevich wrote:
If you're in dire straits you could always use Xerces' deprecated
LSSerializer instead. It will be picked up automatically by Xerces if
you remove serializer.jar from your classpath. Alternatively you could
instantiate the old serializer directly
wrote:
Hi Chad,
Chad La Joie wrote on 06/21/2010 10:18:58 AM:
> Let me preface this by saying that to my understanding Xerces-J and
> Xalan-J now share a common LSSerializer implementations and that this
> implementation is held and maintained by Xalan.
That's correct.
> I
Hi Chad,
Chad La Joie wrote on 06/21/2010 10:18:58 AM:
> Let me preface this by saying that to my understanding Xerces-J and
> Xalan-J now share a common LSSerializer implementations and that this
> implementation is held and maintained by Xalan.
That's correct.
> If that&#x
Stanimir Stamenkov wrote:
Mon, 23 Nov 2009 11:20:23 +, /Chris Simmons/:
I raised a bug (which included a patch) over two
years ago due to different behaviour between the Xerces/Xalan
LSSerializer but it has seemingly been ignored.
https://issues.apache.org/jira/browse/XALANJ-2409
I
Mon, 23 Nov 2009 11:20:23 +, /Chris Simmons/:
I raised a bug (which included a patch) over two
years ago due to different behaviour between the Xerces/Xalan
LSSerializer but it has seemingly been ignored.
https://issues.apache.org/jira/browse/XALANJ-2409
I wonder if LSSerializer bugs are
nymore and decided to combine forces and the Xalan one was chosen as
> > the common codebase because it was better maintained and was making
> > significant improvements to performance. Its LSSerializer
> > implementation was written by a Xerces committer and I have made
> > imp
ebase because it was better maintained and was making
significant improvements to performance. Its LSSerializer
implementation was written by a Xerces committer and I have made
improvements and fixes to it too where I've found issues, so it's
being jointly maintained, though in a differen
Right, that's exactly how it works:
public LSSerializer createLSSerializer() {
try {
Class serializerClass = ObjectFactory.findProviderClass(
"org.apache.xml.serializer.dom3.LSSerializerImpl",
ObjectFactory.findClas
the right one?
--benson
On Sat, Nov 21, 2009 at 10:24 PM, Michael Glavassevich
wrote:
Hi Benson,
We're talking about two different implementations of the DOM Level
3 LSSerializer, the more recently developed one in Xalan
(serializer.jar which Xerces now ships and shares with Xalan)
24 PM, Michael Glavassevich
wrote:
> Hi Benson,
>
> We're talking about two different implementations of the DOM Level 3
> LSSerializer, the more recently developed one in Xalan (serializer.jar which
> Xerces now ships and shares with Xalan) and the much older deprecated one in
&g
ot;" +
> > " text
> > ";
> > results in :
> >
> > text
> >
> >
> >
> > But stripping of this whitespace before will not be too difficult.
> >
> >
> For example:
> String xml = "" +
> " text
> ";
> results in :
>
> text
>
>
>
> But stripping of this whitespace before will not be too difficult.
>
> I feel it is
textchild1> ";
results in :
text
But stripping of this whitespace before will not be too difficult.
I feel it is a pitty that the LSSerializer will not be maintained
anymore, because we do not have alternatives that supply the same
func
Hi Benson,
We're talking about two different implementations of the DOM Level 3
LSSerializer, the more recently developed one in Xalan (serializer.jar
which Xerces now ships and shares with Xalan) and the much older deprecated
one in Xerces. If you're curious about the history on tha
Could I please ask for a bit of clarification? The only LSSerializer I'm
aware of is the DOM level 3 stuff, which, I thought, was the opposite of
obsolete. As someone pointed out here, unlike TraX, it will serialize
doctypes and do other handy things. In general, I'm beginning to
01:19:27 PM:
> Hi Jake,
>
>
> I just tried your suggestion and the spaces are indeed preserved.
> But still, I woud prefer another solution. I do not have any clue
> about the xml (I use xerces in a xml editor) and I do not want to
> change the xml.
> And also I would like
Hi Jake,
I just tried your suggestion and the spaces are indeed preserved.
But still, I woud prefer another solution. I do not have any clue
about the xml (I use xerces in a xml editor) and I do not want to
change the xml.
And also I would like to stay with the LSSerializer (it also
Have you tried xml:space="preserve"?
Jake
On 11/20/2009 4:36 PM, Dick Deneer wrote:
I am still using the deprecated LSSerializer because the xalan
serializer has issues with the pretty print.
But when I have simple elements with only space, the serializer produces
empty elements.
I am still using the deprecated LSSerializer because the xalan serializer has issues with the pretty print.But when I have simple elements with only space, the serializer produces empty elements. Is there a tweak to keep the spaces in this elements?Sample xml:text I attached a simple test
t;
>
> http://www.normeinrete.it/nir/2.2/"; id="art1">
> Art. 1
>
>
> 1.
> text
> http://www.w3.org/HTML/1998/html4";>paragraph
>
>
>
>
> How can I avoid the addition of the namespaces declaration
l...@gmail.com wrote on 03/16/2009 02:16:33 PM:
>
> > Hi,
> >
> > I need to use the LSSerializer provided by xerces to serialize a DOM
> > document subtree without namespaces completion processing, i.e., the
> > desired output is just the xml serialization of the subtree
Hi Tommaso,
tommaso.agnol...@gmail.com wrote on 03/16/2009 02:16:33 PM:
> Hi,
>
> I need to use the LSSerializer provided by xerces to serialize a DOM
> document subtree without namespaces completion processing, i.e., the
> desired output is just the xml serialization of the
Hi,
I need to use the LSSerializer provided by xerces to serialize a DOM
document subtree without namespaces completion processing, i.e., the desired
output is just the xml serialization of the subtree as one could extract it
by selection from the whole document serialization.
To this end, if I
yluk" <[EMAIL PROTECTED]> wrote on 06/28/2007 12:01:40
PM:
> Why is the pretty printing using LSSerializer so bad compared to
> XMLSerializer (which is deprecated)?
>
> Are there any plans to improve it? If you can make XMLSerializer
> work properly you should be able t
Why is the pretty printing using LSSerializer so bad compared to
XMLSerializer (which is deprecated)?
Are there any plans to improve it? If you can make XMLSerializer work
properly you should be able to make LSSerializer work properly.
It's hard to justify moving away from the depre
with (assuming it's
Xerces).
Note that "format-pretty-print" has only been implemented since
Xerces
2.8.0. If you're using Xerces 2.9.0 the LSSerializer is based on
Xalan
which has different behaviour with respect to pretty-printing.
Rafał Gierusz <[EMAIL PROTECTED]>
plemented since Xerces
> 2.8.0. If you're using Xerces 2.9.0 the LSSerializer is based on Xalan
> which has different behaviour with respect to pretty-printing.
>
> Rafał Gierusz <[EMAIL PROTECTED]> wrote on 04/05/2007 05:39:51 AM:
>
>> Hello,
>>
>
You haven't said what release you tried this with (assuming it's Xerces).
Note that "format-pretty-print" has only been implemented since Xerces
2.8.0. If you're using Xerces 2.9.0 the LSSerializer is based on Xalan
which has different behaviour with respect to
Hello,
I would like to make "pretty-print" xml using LSSerializer, so a write:
LSSerializer serializer = ...
serializer.getDomConfig().setParameter("format-pretty-print", true);
then I get string with "pretty-print" xml using metod:
serializer.writeToString(.
blic void writeXML(Element element, File outputFile) throws Exception{
> DOMImplementation domImpl =
> element.getOwnerDocument().getImplementation();
>
> DOMImplementationLS domImplLS = (DOMImplementationLS)
> domImpl.getFeature("LS", "3.0");
>
> LSSeri
n domImpl =
element.getOwnerDocument().getImplementation();
DOMImplementationLS domImplLS = (DOMImplementationLS)
domImpl.getFeature("LS", "3.0");
LSSerializer serializer = domImplLS.createLSSerializer();
LSOutput serializerOut = domImplLS.createLSOutput();
serializerOut.setC
t; needs to write
> out XML and later read it back in. I'm using the LSSerializer to
> write out the
> root element node of my document to a string and then using a FileWriter
to
> write it out to disk. Then I use a FileInputStream to read it in
> and parse it
>
I'm using Xerces-J 2.8.0 as my endorsed JAXP 1.3 parser. My code needs to write
out XML and later read it back in. I'm using the LSSerializer to write out the
root element node of my document to a string and then using a FileWriter to
write it out to disk. Then I use a FileInpu
Andy Kriger <[EMAIL PROTECTED]> wrote on 08/30/2005 10:18:09 AM:
> Does LSSerializer have a way to control whether empty elements are
> written as or ? We have an application
> that requires empty elements to be written in the first manner (even
> though they're both
Does LSSerializer have a way to control whether empty elements are
written as or ? We have an application
that requires empty elements to be written in the first manner (even
though they're both equivalent, it makes a difference to a non-XML
saavy 3rd-party application we use).
Is there
37 matches
Mail list logo
