Hi Scott, thks for taking interest.
I'm building a GUI, presenting xml on screen. Its
ment to work at all xml objects, not only my own. So it's not my choice, if the
file contains attribute, it's displayed.
I could mail you a screen shot, if you
like.
Thks and regards
Endre Furnes
Not
Sorry, I've missed that point. I can use them, anyhow.
I use the xerces-2.0.0 beta2
Endre Furnes
Notion
- Original Message -
From: Elena Litani <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 07, 2001 8:28 PM
Subject: Re: sorting attributes
>
>
> "Notion, Endre
I'm not sure I follow what you are trying to do,
but if order is important, then use instead of
attributes. The XML spec guarantees elements will remain in the same order
they are created in.
Scott
- Original Message -
From:
Notion,
Endre Furnes
To: [EMAIL PROTECTED
"Notion, Endre Furnes" wrote:
>The reason why I replaced the parser, was that crimson removed
> '\n' and '\t' from the attribute values. (I'll do that myself).
> Xerces is fine in both respects.
This is really interesting.. What version of Xerces are you using?
Xerces conforms to XML 1.0 Att
Thks for rapid responce, Scott.
A pitty, though that I can't switch that off.
Looking at it, cocoon's build file has sorted attributes, so I'm sure you are
right. The thing is, I'm working on a GUI, and I think it matters for clarity
that the ex. build file says: -name, -depends, -if, -un
If Xerces is *not* removing '\n' and '\t' from attribute values
(actually, replacing them with space characters) it has a problem - this
is supposed to be done by all XML processors. See XML recommendation
section 3.3.3 Attribute-Value Normalization for details.
- Dennis
Notion, Endre Furnes w
According to the XML standard, attribute order is
not guaranteed and is implementation dependent. So, (and I'm guessing
here), I doubt there is a way to turn it off in Xerces. They probably sort
it in order to do a fast binary search lookup by attribute name, so the sorting
is a side-effec
Hi all. I'm a newbee to xerces. Has just replaced
the crimson with xerces, and access it via jaxp interface.
The reason why I replaced the parser, was that
crimson removed '\n' and '\t' from the attribute values. (I'll do that myself).
Also some annoyment in relative versus absolute dtd poi
Hi,
It seems that the isValidating() method of the implementation of SAXParser
doesn't query the underlying XMLReader instance.
The following code:
---
SAXParserFactory spf = SAXParserFactory.newInstance();
SAXParser sp = spf.newSAXParser();
XMLReader xr = sp.getX
At 1:32 PM +0900 11/7/01, Andy Clark wrote:
richard cai wrote:
However, I just ran into a case in that the presense
of seems to screw up the parsing (to be
exact, public void characters(char ch[], int start,int
length) seems no longer be able to function.). Any
ideas?
By any chance is the p
richard cai wrote:
> However, I just ran into a case in that the presense
> of seems to screw up the parsing (to be
> exact, public void characters(char ch[], int start,int
> length) seems no longer be able to function.). Any
> ideas?
Any more info?
--
Andy Clark * IBM, TRL - Japan * [EMAIL PR
rpcee wrote:
> Is it correct to extend XMLDocumentParser to build a object model
> from an XNI stream, or is there a preferred way.
That would certainly work. Do whatever is best for you.
Technically, you don't even need to extend the document
parser because in Xerces2, the parser configuration
rpcee wrote:
> xerces.jar is uncompressed. Is there a reason not to create a
> compressed version?
I forget the reason exactly but it has something to do with
older Java VMs and/or browsers that cannot load Jars that have
been compressed. Leaving it uncompressed allows it to work for
everyone rig
13 matches
Mail list logo
