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 Elena Litani <el...@ca.ibm.com> on 2003/11/21 18:18:23 UTC
[ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Hi all,
The Xerces-J team is very happy to announce that version 2.6.0 of
Xerces-J is now available.
This release provides an experimental implementation of the Document
Object Model Level 3 Core and Load/Save Candidate Recommendations (see
beta-dom3-Xerces-J-bin.2.6.0.zip) and also brings Xerces-J into
compliance with the XML
1.1 Proposed Recommendation (except that it does not yet provide an
option to enable normalization checking as described in section 2.13 of
this specification) and Namespaces in XML 1.1 Proposed Recommendation.
Specifically, the significant changes introduced in this release are:
* Improved the scanning of attribute lists, both small and large.
[Michael Glavassevich]
* Reimplemented XML11Configuration (the default configuration),
improving performance during reset; accomplished primarily by adding an
internal feature which allows components to query whether or not they
need to read features and properties from the configuration. [Elena
Litani]
* Modified XML Schema interfaces (org.apache.xerces.xs) and updated the
implementation accordingly. Methods were added to expose actual values
and their types and new interfaces were added for loading XSModels. In
addition, fixed various bugs in the implementation and PSVIWriter
sample. [Sandy Gao, Pete Lloyd, Elena Litani]
* Implemented the DOM Level 3 Core and Load and Save Candidate
Recommendations. [Neil Delima, Neeraj Bajaj, Michael Glavassevich, Elena
Litani, Ramesh Mandava, Gopal Sharma, K.Venugopal]
* Added support for the 'well-formed' feature in DOM Level 3 Core.
[Neeraj Bajaj]
* Added XML 1.1 support to DOM Level 3. [K.Venugopal]
* Fixed the serializer so that TAB (0x9), LF (0xA), CR (0xD), NEL (0x85)
and LSEP (0x2028) are escaped where appropriate in order to allow these
characters to be roundtripped. [Neil Delima, Elena Litani]
* Implemented experimental support for the XML 1.1 PR. This still
excludes section 2.13. [Michael Glavassevich]
* Fixed a bug which could cause the parser to run out of memory (or
other resources) while parsing documents containing many entity
references. [Michael Glavassevich]
* Implemented missing support for Registry-based Naming Authority in the
URI implementation. [Michael Glavassevich]
* Modified the XJavac task used by the build file so that Xerces can be
built on Linux with Blackdown JDK 1.4. [Amit Kapoor]
* Removed static references to sun.io.CharToByteConverter which made it
impossible to compile Xerces on platforms that do not have this internal
class. With binaries on such platforms, the serializer was unusable with
many encodings. [Michael Glavassevich]
* Added support for XML Base to the XInclude implementation. Fixed
various bugs regarding text inclusion and relative URI resolution in the
XInclude implementation. [Michael Glavassevich, Peter McCracken, Neil
Pitman]
* Implemented errata from the XML 1.0 Second Edition Specification.
[Neil Delima, Michael Glavassevich, Glenn Marcy, Peter McCracken]
* Moved Xerces' SAX support up to SAX 2.0.1. [Elena Litani]
* Fixed bugs in the XML 1.1 entity scanner that in some cases treated
NEL (0x85) and LSEP (0x2028) as white space characters in internal
entities, and not as end of line characters in external entities.
[Michael Glavassevich]
* Fixed bug in HTML DOM implementation that would cause a hierarchy
request error by trying to move a doctype node to be a child of the
<html> element. [Andy Clark]
* Fixed various bugs. [Neil Delima, Sandy Gao, Neil Graham, Michael
Glavassevich, Elena Litani, Lisa Martin, Peter McCracken, Gareth Reakes,
Neeraj Bajaj, K.Venugopal, Ramesh Mandava, Kohsuke Kawaguchi, Gopal
Sharma]
For more information please visit: http://xml.apache.org/xerces2-j/
Thank you,
--
Elena Litani / IBM Toronto
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
Could somebody add version 2.6.0 to the Bugzilla page? I've already
identified one minor bug in 2.6.0 which I reported against 2.5.0.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Why a 1.0 configuration is not enough and a property is required
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 6:05 PM -0800 11/21/03, Arnaud Le Hors wrote:
>Andy Clark wrote:
>> However, it
>> would be nice to have a setting that allows people
>> to make Xerces strictly enforce a specific version
>> over another.
>>
>
>If somebody really wants this he/she can always have his/her own
>configuration I suppose. But I don't see any use case for this so I
>wouldn't spend resources on this.
The custom configuration neatly solves my needs. However, last night
I realized why it doesn't solve everyone's. Consider this:
Currently when the Java class loader loads the Builder class it sets
the XMLParserConfiguration property to point at XOM's custom 1.0 only
configuration. This guarantees that XOM will get the 1.0 features it
requires. Good.
However, because System properties are global it also ensures that
all other uses of Xerces within the same VM are also going to pick up
XOM's configuration. They may not want this. They may want a 1.1
savvy parser, or they may even want a different configuration for
completely different reasons having nothing to do with the difference
between 1.0 and 1.1.
The configuration needs to set on per-parser basis. Each XMLReader
object should be able to set its own configuration independent of the
configurations used for other XMLReaders. Currently, I don't see any
way to do this from SAX. Perhaps there's a way to do this from XNI,
but even if there is, this requires asking authors to tie their code
to Xerces specifically rather than programming to the generic SAX
interface. For more discussion of why this is a bad thing see Item 31
of Effective XML, Program to Standard APIs,
http://www.cafeconleche.org/books/effectivexml/chapters/31.html
The simplest way I've though of to allow individual XMLReaders to
have their own configuration is by setting a SAX property. For
example,
XMLReader parser = XMLReaderFactory.createXMLReader();
parser.setProperty(
"http://apache.org/xerces/properties/ParserConfigurationClass",
"com.elharo.xml.MyParserConfiguration");
This is much more granular than the existing all or nothing scheme. I
think this would be useful to anybody who needs a custom parser
configuration for any reason. It would not interfere with the
existing API at all. The only complexity increase would be a few more
paragraphs in the Xerces features and properties page.
The one doubt I have about this is whether it's possible to change
the parser configuration after the parser has been instantiated. If
it is, then this is straight-forward to implement.If it's not, then
more thought would need to be applied to how to make that possible,
and it wouldn't be such an easy fix. But I still think it's an
important one. Per-VM parser configuration just isn't granular enough.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
>As Arnaud mentioned in a previous post, if you absolutely don't want
>XML 1.1 support you can override the default configuration [1]. This is
>fairly simple to accomplish and doesn't require you to change any of your
>code. There are other parser configurations (besides the default) included
>with the distribution which you can choose to use instead, so you don't
>need to write one yourself.
>
Excellent. Thanks. I had figured out how to do this by changing the
code and recompiling, but I'd rather not do that if I don't have to,
and it looks like maybe I don't have to.. That page does says,
"Moreover, the DOM and SAX parsers created using the JAXP interfaces
will use the specified parser configuration transparently and without
need to call additional methods to set the parser configuration."
What about SAX parsers created using the SAX XMLReaderFactory class
rather than JAXP? Are they also set up with the relevant parser
configuration?
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Michael Glavassevich <mr...@apache.org>.
As Arnaud mentioned in a previous post, if you absolutely don't want
XML 1.1 support you can override the default configuration [1]. This is
fairly simple to accomplish and doesn't require you to change any of your
code. There are other parser configurations (besides the default) included
with the distribution which you can choose to use instead, so you don't
need to write one yourself.
[1] http://xml.apache.org/xerces2-j/faq-xni.html#override-default-config
On Fri, 21 Nov 2003, Arnaud Le Hors wrote:
> No, what you're describing does NOT require any option on the parser.
> The parser will act according to the XML declaration in your file, or
> lack of. So, if you don't have any XML declaration or if you have one
> and it specifies it is an XML 1.0 file (with version="1.0") the parser
> will enforce 1.0 conformance.
> Only when you have an XML declaration with version="1.1" in your file
> the parser will use 1.1 conformance rules.
> --
> Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
>
>
>
> Elliotte Rusty Harold wrote:
> > At 6:05 PM -0800 11/21/03, Arnaud Le Hors wrote:
> >
> >> If somebody really wants this he/she can always have his/her own
> >> configuration I suppose. But I don't see any use case for this so I
> >> wouldn't spend resources on this.
> >>
> >
> > The use case is interoperating with the vast installed base of systems
> > and software that expect and rely on XML 1.0 rules being followed. I for
> > one need and expect a parser to report all well-formedness errors as
> > required by XML 1.0. If Xerces cannot easily be configured to do that,
> > then I will have to consider using another parser. Sadly the number of
> > genuinely conformant parsers written in Java is very small. Up till now
> > Xerces had been clearly the best. Possibly, if I don't find a better
> > alternative, and if there's no simple way to turn Xerces into a
> > conformant parser, then I will have to fork it. :-(
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
--
---------------------------
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 11:04 AM -0800 11/23/03, Andy Clark wrote:
>XML 1.1 does solve real needs, just perhaps not
>your specific needs. Remember, you're not the only
>user of XML technology in the world.
May I ask whose needs? I have repeatedly asked for evidence that
anyone actually needs this. I have repeatedly been met with claims
that merely asking the question is somehow morally offensive. To this
day, I know exactly one person who has expressed some interest in
using the new features of XML 1.1. I know one other person who has
said they might theoretically need this at some point in the future,
though they have not actually encountered such a need yet. It's not
like there's a clamor of people demanding this stuff.
>This reminds me of your posts on xml-dev a long
>time ago when people were discussing XML 1.1. I
>was working at the IBM research labs in Japan at
>the time and people there were rolling their eyes
>(figuratively) at your suggestion that English
>was good enough for element and attribute
>names... ;)
I'm pretty damn sure I never said any such thing. I think you're
either misremembering something I did say, or taking it so severely
out of context as to distort its meaning. I ask that you either
produce evidence for that claim by URL reference to the xml-dev
archives, or retract that statement.
>I think we all need to remember that there are many
>perspectives and solutions to any problem. And some
>of them may not make much sense to an individual but
>may have value to the collective group.
Indeed. My claim is that there is no such collective group for XML
1.1. I challenge you to produce actual users who need these new
features. If you can do that, then step two is to demonstrate that
the benefits of XML 1.1 for these users outweigh the costs imposed on
the rest of the world by XML 1.1. To date, no one has been willing to
even attempt this calculation, I think because they realize that the
benefits for a very, very few are vastly outweighed by the
disadvantages suffered by the very, very many.
I have no fundamental, technical objection to adding the new scripts
in Unicode 3.0 and 4.0 to XML. Well, I do object to adding the
musical symbols, and the mathematical letters are a security problem
that's going to bite somebody badly sooner or later, but I don't mind
Burmese, Cambodian, Cherokee, and so forth. However, I just don't
think the minor benefits of adding these scripts come close to
outweighing the costs of the entire proposal.
I do think that adding NEL (and the Unicode line separator character)
to XML is technically flawed and has huge costs in and of itself,
irrespective of the problems of adding any new version of XML. I also
think that Unicode normalization, the way it is implemented in XML
1.1, is pointless and confusing. I dispute these on their own merits
or lack thereof. Adding new scripts I could accept if the total
benefits outweighed the costs. Sadly though, that's not even close to
true here.
>> anything I'm surprised it's as good as it is. There really are
>>very few design mistakes in XML 1.0. It's a very nice piece of work.
>
>Really?
>
>Despite having worked with XML awhile now, I'm still
>no big fan of the syntax. I wish that the DTD syntax
>(and inline grammar associations, in general) had
>been broken out of the original spec. Namespaces,
>like Bray's skunkworks that you mention, should have
>been incorporated from the beginning. And I have no
>need, personally, of notations which would probably
>make SGML folks bristle at the thought... ;)
If I were going back in time to join the XML Working Group circa
1996, notations are certainly one of the thing I would argue
against. Overall, though, I don't find them so much harmful as
unused. Removing them would make the spec smaller and simpler. But
they don't seem to cause a lot of problems in day-to-day use as
contrasted with, for example, the internal DTD subset, which lots of
parsers including Xerces still don't get quite right.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Andy Clark <an...@apache.org>.
Elliotte Rusty Harold wrote:
> Well, I don't know about any new version. So far we've only got one new
> version,and it's a dog. Maybe in the future the W3C will come out with
> one that's actually useful, and solves real needs.
XML 1.1 does solve real needs, just perhaps not
your specific needs. Remember, you're not the only
user of XML technology in the world.
This reminds me of your posts on xml-dev a long
time ago when people were discussing XML 1.1. I
was working at the IBM research labs in Japan at
the time and people there were rolling their eyes
(figuratively) at your suggestion that English
was good enough for element and attribute
names... ;)
I think we all need to remember that there are many
perspectives and solutions to any problem. And some
of them may not make much sense to an individual but
may have value to the collective group.
> anything I'm surprised it's as good as it is. There really are very few
> design mistakes in XML 1.0. It's a very nice piece of work.
Really?
Despite having worked with XML awhile now, I'm still
no big fan of the syntax. I wish that the DTD syntax
(and inline grammar associations, in general) had
been broken out of the original spec. Namespaces,
like Bray's skunkworks that you mention, should have
been incorporated from the beginning. And I have no
need, personally, of notations which would probably
make SGML folks bristle at the thought... ;)
> I prefer the alternate approach of driving every nail I can find into
> XML 1.1's coffin so that we don't have to transition at all. After all,
> it's not like XML 1.1 is actually useful in any significant way.
I don't think there's a need to be so antagonistic.
It's just not helpful.
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Arnaud Le Hors <le...@us.ibm.com>.
You appear to have such a self centered view of the world and what is
useful that I'm not going to bother arguing any further.
Life would also be easier if the whole world spoke english, but guess
what, it ain't the case...
So nail yourself into your little corner and stay there while the W3C
tries to make the world wide web really world wide. That's fine with me.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
Elliotte Rusty Harold wrote:
> At 12:34 PM -0800 11/22/03, Arnaud Le Hors wrote:
>
>> Oh I see, you're one of those who just don't want to hear about any
>> new version of XML.
>
>
> Well, I don't know about any new version. So far we've only got one new
> version,and it's a dog. Maybe in the future the W3C will come out with
> one that's actually useful, and solves real needs.
>
>> But as you say it yourself, the idea that there is only one way to
>> parse XML is already an illusion. The list of possible behaviors for a
>> compliant XML 1.0 parser is already large enough that one cannot
>> blindly rely on interoperability just because he uses XML. You have to
>> deal with a whole range of variations from a minimally conformant non
>> validating parser to a fully conformant validating parser, with or
>> without namespaces support, with or without XML Schema validation,
>> with or without XInclude support, and the list goes on... So the
>> reality is that adding XML 1.1 to the mix doesn't make much
>> difference. And ignoring the need for evolution is absurd.
>
>
> XML 1.1 is qualitatively different. None of the examples you cite change
> the definition of what is a well-formed or malformed XML document. XML
> 1.1 does. All of the examples you cite can be parsed with a minimally
> conformant XML 1.1 parser. An XML 1.1 document cannot be.
>
>> Believe me, I'm the first to wish they got XML 1.0 right in the first
>> place, but they didn't. And I don't blame them, that's life. Just be
>> glad that those of us who fought to get XML 1.1 open enough so that we
>> won't need to revise it again when a new version of Unicode comes out
>> prevailed.
>
>
> I'm not surprised it wasn't right the first time either. In fact if
> anything I'm surprised it's as good as it is. There really are very few
> design mistakes in XML 1.0. It's a very nice piece of work.
> Unfortunately XML 1.1 doesn't fix the mistakes in XML 1.0. It just makes
> several new ones, among them allowing characters that aren't even
> defined in Unicode and never will be to be used in XML names.
>
>> What I think we need is to define some kind of profiles that nails
>> down the number of possible behaviors to just a few. Something that is
>> named, that implementers can advertise as something they support, and
>> that users can look for. Similar to what you get with the Java
>> platforms labels J2EE, J2SE, J2ME, etc.
>
>
> Now if XML 1.1 had done that it might have some purpose in the world.
>
>> I was discussing this with Tim Berners-Lee this week and he agrees
>> that it would be good. However, he thought that should be a new
>> version of XML. Something I'd rather avoid, but I have to admit that
>> it'd be good to be able to label your document somehow so that the
>> processor could tell whether it can process it as you want it to be
>> processed. This also brings us back into the processing model issue
>> which has been in the air for a while. I don't see these problems to
>> be solved any time soon unfortunately.
>
>
> I prefer Tim Bray's skunkworks approach of removing the uninteroperable
> pieces. Otherwise we're just back in SGML land where no two parsers
> acted alike, and documents weren't interoperable in practice. Getting
> rid of the SGML declaration was a good thing.
>
> As Santayna wrote in 1905, "Those who cannot remember the past are
> condemned to repeat it." The people who gave us XML remembered the
> history of SGML, and thus didn't repeat its mistakes. I'm saddened to
> see that those who've come after them have forgotten what went wrong
> with SGML, and are proceeding to repeat its mistakes, one after the other.
>
>> So, in the meantime, the best we can do is to work on making 1.1
>> omnipresent as quickly as possible so that we can put the burden of
>> transitioning behind us.
>
>
> I prefer the alternate approach of driving every nail I can find into
> XML 1.1's coffin so that we don't have to transition at all. After all,
> it's not like XML 1.1 is actually useful in any significant way.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 12:34 PM -0800 11/22/03, Arnaud Le Hors wrote:
>Oh I see, you're one of those who just don't want to hear about any
>new version of XML.
Well, I don't know about any new version. So far we've only got one
new version,and it's a dog. Maybe in the future the W3C will come out
with one that's actually useful, and solves real needs.
> But as you say it yourself, the idea that there is only one way to
>parse XML is already an illusion. The list of possible behaviors for
>a compliant XML 1.0 parser is already large enough that one cannot
>blindly rely on interoperability just because he uses XML. You have
>to deal with a whole range of variations from a minimally conformant
>non validating parser to a fully conformant validating parser, with
>or without namespaces support, with or without XML Schema
>validation, with or without XInclude support, and the list goes
>on... So the reality is that adding XML 1.1 to the mix doesn't make
>much difference. And ignoring the need for evolution is absurd.
XML 1.1 is qualitatively different. None of the examples you cite
change the definition of what is a well-formed or malformed XML
document. XML 1.1 does. All of the examples you cite can be parsed
with a minimally conformant XML 1.1 parser. An XML 1.1 document
cannot be.
>Believe me, I'm the first to wish they got XML 1.0 right in the
>first place, but they didn't. And I don't blame them, that's life.
>Just be glad that those of us who fought to get XML 1.1 open enough
>so that we won't need to revise it again when a new version of
>Unicode comes out prevailed.
I'm not surprised it wasn't right the first time either. In fact if
anything I'm surprised it's as good as it is. There really are very
few design mistakes in XML 1.0. It's a very nice piece of work.
Unfortunately XML 1.1 doesn't fix the mistakes in XML 1.0. It just
makes several new ones, among them allowing characters that aren't
even defined in Unicode and never will be to be used in XML names.
>What I think we need is to define some kind of profiles that nails
>down the number of possible behaviors to just a few. Something that
>is named, that implementers can advertise as something they support,
>and that users can look for. Similar to what you get with the Java
>platforms labels J2EE, J2SE, J2ME, etc.
Now if XML 1.1 had done that it might have some purpose in the world.
>I was discussing this with Tim Berners-Lee this week and he agrees
>that it would be good. However, he thought that should be a new
>version of XML. Something I'd rather avoid, but I have to admit that
>it'd be good to be able to label your document somehow so that the
>processor could tell whether it can process it as you want it to be
>processed. This also brings us back into the processing model issue
>which has been in the air for a while. I don't see these problems to
>be solved any time soon unfortunately.
I prefer Tim Bray's skunkworks approach of removing the
uninteroperable pieces. Otherwise we're just back in SGML land where
no two parsers acted alike, and documents weren't interoperable in
practice. Getting rid of the SGML declaration was a good thing.
As Santayna wrote in 1905, "Those who cannot remember the past are
condemned to repeat it." The people who gave us XML remembered the
history of SGML, and thus didn't repeat its mistakes. I'm saddened to
see that those who've come after them have forgotten what went wrong
with SGML, and are proceeding to repeat its mistakes, one after the
other.
>So, in the meantime, the best we can do is to work on making 1.1
>omnipresent as quickly as possible so that we can put the burden of
>transitioning behind us.
I prefer the alternate approach of driving every nail I can find into
XML 1.1's coffin so that we don't have to transition at all. After
all, it's not like XML 1.1 is actually useful in any significant way.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Oh I see, you're one of those who just don't want to hear about any new
version of XML. But as you say it yourself, the idea that there is only
one way to parse XML is already an illusion. The list of possible
behaviors for a compliant XML 1.0 parser is already large enough that
one cannot blindly rely on interoperability just because he uses XML.
You have to deal with a whole range of variations from a minimally
conformant non validating parser to a fully conformant validating
parser, with or without namespaces support, with or without XML Schema
validation, with or without XInclude support, and the list goes on... So
the reality is that adding XML 1.1 to the mix doesn't make much
difference. And ignoring the need for evolution is absurd.
Believe me, I'm the first to wish they got XML 1.0 right in the first
place, but they didn't. And I don't blame them, that's life. Just be
glad that those of us who fought to get XML 1.1 open enough so that we
won't need to revise it again when a new version of Unicode comes out
prevailed.
What I think we need is to define some kind of profiles that nails down
the number of possible behaviors to just a few. Something that is named,
that implementers can advertise as something they support, and that
users can look for. Similar to what you get with the Java platforms
labels J2EE, J2SE, J2ME, etc.
I was discussing this with Tim Berners-Lee this week and he agrees that
it would be good. However, he thought that should be a new version of
XML. Something I'd rather avoid, but I have to admit that it'd be good
to be able to label your document somehow so that the processor could
tell whether it can process it as you want it to be processed. This also
brings us back into the processing model issue which has been in the air
for a while. I don't see these problems to be solved any time soon
unfortunately.
So, in the meantime, the best we can do is to work on making 1.1
omnipresent as quickly as possible so that we can put the burden of
transitioning behind us.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
Elliotte Rusty Harold wrote:
> At 10:03 AM -0800 11/22/03, Arnaud Le Hors wrote:
>
>> I still don't understand how you think you increase interoperability
>> by limiting a system in what it takes as input, but I guess it's ok...
>
>
> There's no big secret here. It's *exactly* how XML increases
> interoperability by requiring draconian well-formedness checking. As the
> number of maybe right/maybe wrong formats increases interoperability
> decreases. The XML philosophy is fail as early and as fast as possible,
> and that works.
>
> When I see XML 1.1, I want the parser to fail immediately and at the
> first opportunity. I don't want to let the document propagate through
> the system until it finally runs up against some component that can't
> handle it. I certainly don't want to accept a million documents
> needlessly labelled as XML 1.1, only to have the system fail
> unexpectedly in production when one of those documents uses a NEL or a
> Linear B tag name or something equally pointless. I want to debug it as
> near the source as possible, not a thousand miles and six months away.
>
> Failing fast on any variation from a single syntax is one of the pillars
> of XML's interoperability. It's sad to see this lesson has not been
> learned or the principle adopted by so many purveyors of XML tools. In
> fact, I'd venture to say that most non-parser XML tools are far too
> accepting of bad data.
>
> In any case, I have now added unit tests to my code to verify that
> version="1.1" (and 1.2, and 2.0) generate a fatal error; so I should
> notice if this bug slips in again in the future, either in Xerces or a
> different parser. I'm not surprised that all other parsers haven't been
> noticing this. I've certainly found a lot of bugs in them. Xerces 2.6
> currently has one conformance bug that affects me
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24124>. The next best
> parser, the latest Oracle beta, has about ten. The remaining parsers
> written in Java all number in the dozens.
>
> Sadly, XML's goal of being simple enough to be implemented by the
> desperate Perl hacker was not met. If after six years and the
> application of huge amounts of effort and brain power, we still don't
> have one parser that gets the basic spec right, then there's something
> wrong with the spec. Sadly most of these problems are not addressed by
> XML 1.1. :-(
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 10:03 AM -0800 11/22/03, Arnaud Le Hors wrote:
>I still don't understand how you think you increase interoperability
>by limiting a system in what it takes as input, but I guess it's
>ok...
There's no big secret here. It's *exactly* how XML increases
interoperability by requiring draconian well-formedness checking. As
the number of maybe right/maybe wrong formats increases
interoperability decreases. The XML philosophy is fail as early and
as fast as possible, and that works.
When I see XML 1.1, I want the parser to fail immediately and at the
first opportunity. I don't want to let the document propagate through
the system until it finally runs up against some component that can't
handle it. I certainly don't want to accept a million documents
needlessly labelled as XML 1.1, only to have the system fail
unexpectedly in production when one of those documents uses a NEL or
a Linear B tag name or something equally pointless. I want to debug
it as near the source as possible, not a thousand miles and six
months away.
Failing fast on any variation from a single syntax is one of the
pillars of XML's interoperability. It's sad to see this lesson has
not been learned or the principle adopted by so many purveyors of XML
tools. In fact, I'd venture to say that most non-parser XML tools are
far too accepting of bad data.
In any case, I have now added unit tests to my code to verify that
version="1.1" (and 1.2, and 2.0) generate a fatal error; so I should
notice if this bug slips in again in the future, either in Xerces or
a different parser. I'm not surprised that all other parsers haven't
been noticing this. I've certainly found a lot of bugs in them.
Xerces 2.6 currently has one conformance bug that affects me
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24124>. The next
best parser, the latest Oracle beta, has about ten. The remaining
parsers written in Java all number in the dozens.
Sadly, XML's goal of being simple enough to be implemented by the
desperate Perl hacker was not met. If after six years and the
application of huge amounts of effort and brain power, we still don't
have one parser that gets the basic spec right, then there's
something wrong with the spec. Sadly most of these problems are not
addressed by XML 1.1. :-(
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Elliotte Rusty Harold wrote:
> An XML 1.0 parser will reject an XML 1.1 document.
Are you so sure? :-)
We did a small survey in the XML Core WG which revealed that the
behavior of XML 1.0 parsers varied greatly when fed with a document with
a version other than 1.0. Some generate wellformedness errors all right,
but others merely produce a warning or do nothing, assuming the rest of
the documents does qualify as 1.0.
I still don't understand how you think you increase interoperability by
limiting a system in what it takes as input, but I guess it's ok...
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 9:02 PM -0800 11/21/03, Arnaud Le Hors wrote:
>No, what you're describing does NOT require any option on the
>parser. The parser will act according to the XML declaration in your
>file, or lack of. So, if you don't have any XML declaration or if
>you have one and it specifies it is an XML 1.0 file (with
>version="1.0") the parser will enforce 1.0 conformance.
>Only when you have an XML declaration with version="1.1" in your
>file the parser will use 1.1 conformance rules.
No, that's not at all what I want. In XML 1.0, XML 1.1 documents are
malformed. They have been for years. An XML 1.0 parser will reject an
XML 1.1 document. This is the behavior I need. I don't want
auto-detection. I want XML 1.1 documents dropped on the floor with a
fatal error as the XML 1.0 specification requires. I do not want to
process them.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Arnaud Le Hors <le...@us.ibm.com>.
No, what you're describing does NOT require any option on the parser.
The parser will act according to the XML declaration in your file, or
lack of. So, if you don't have any XML declaration or if you have one
and it specifies it is an XML 1.0 file (with version="1.0") the parser
will enforce 1.0 conformance.
Only when you have an XML declaration with version="1.1" in your file
the parser will use 1.1 conformance rules.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
Elliotte Rusty Harold wrote:
> At 6:05 PM -0800 11/21/03, Arnaud Le Hors wrote:
>
>> If somebody really wants this he/she can always have his/her own
>> configuration I suppose. But I don't see any use case for this so I
>> wouldn't spend resources on this.
>>
>
> The use case is interoperating with the vast installed base of systems
> and software that expect and rely on XML 1.0 rules being followed. I for
> one need and expect a parser to report all well-formedness errors as
> required by XML 1.0. If Xerces cannot easily be configured to do that,
> then I will have to consider using another parser. Sadly the number of
> genuinely conformant parsers written in Java is very small. Up till now
> Xerces had been clearly the best. Possibly, if I don't find a better
> alternative, and if there's no simple way to turn Xerces into a
> conformant parser, then I will have to fork it. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re forcing XML 1.0 (was Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available)
Posted by Joseph Kesselman <ke...@us.ibm.com>.
Personal reactions, for whatever it's worth:
1) It's definitely worth letting users insist on 1.0 output, for the case
where you know you're going to be sending the data to an old tool which
won't handle 1.1.
2) On the other hand I agree that it's in the best interests of the
community as a whole to try to push everyone toward tolerating XML 1.1.
(It's not as if doing so is a serious hardship, especially if you don't
expect your users' documents to use the features which make 1.1 different
from 1.0.)
3) On the other other hand, I think it's worth clearly documenting how to
obtain a 1.0-only parser for those (rare, but not impossible) cases where
it really is the right answer. I'm not entirely convinced this has to be
made *easy*, given (2) above, but if we can do it without adverse impact I
wouldn't object to offering it. It does sorta fall in the category of "Are
you REALLY sure? Are you aware that you're giving a competetive advantage
to anyone who doesn't enforce this archaic limitation? Are you aware that
you're going to upset your customers, who don't want to be forced to code
down to your level? Are you aware that this really isn't saving you much
work?"
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Andy Clark <an...@apache.org>.
Arnaud Le Hors wrote:
> Because I think it's wrong to let users limit their system to 1.0, so
> I'm against making this easy. All sorts of people misled by people like
> Elliotte will turn this on without understanding what it means.
We give users other potentially problematic features
with the assumption that they must know what they're
getting themselves into before they use them. I don't
see a problem with this approach as long as the
default is set to encourage "the right thing".
But I'm strictly against deciding for users what they
should and should not be doing. If there's a real user
need (and I think there one in this case) then we
should provide a solution.
All of this should be taken with a grain of salt,
however. There are reasons such as performance impact
that may rule out implementing certain features (e.g.
editor-only functionality that greatly degrades the
parser for all other users).
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 12:24 PM -0800 11/24/03, Arnaud Le Hors wrote:
>I choose to end the debate with Elliotte because I think it is
>pointless to discuss the value of XML 1.1. This debate has already
>taken place in another forum: the W3C, with far more parties
>involved than Elliotte and me. And I respect that process and its
>result. I think it is essential that once the stds debate is over we
>all get behind the standard and endorse it independently of we
>individually think.
The nice thing about standards is that there are so many of them to
choose from. I choose XML 1.0. In fact, I think it's more standard
than XML 1.1 since there's vastly more software that implements it.
Stare decisis is an important characteristic of standards. If
standards are to be useful then once a decision has been made it
should not be revisited without a damn good reason. Sometimes you do
need to adjust a standard to add functionality that was not
originally anticipated. I don't think this is what XML 1.1 is doing.
Arguably, the new name characters add new functionality. The rest of
it is pure "We don't like what the standard says so we're going to
change it." It demonstrates a lack of respect for the standards
process.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Arnaud Le Hors <le...@us.ibm.com>.
This is not what I said. I talked about people who "will turn this on
without understanding what it means." I disagree with Elliotte but it's
clear to me that he understands what this is about.
I choose to end the debate with Elliotte because I think it is pointless
to discuss the value of XML 1.1. This debate has already taken place in
another forum: the W3C, with far more parties involved than Elliotte and
me. And I respect that process and its result. I think it is essential
that once the stds debate is over we all get behind the standard and
endorse it independently of we individually think.
Elliotte appears to have different views on that, that's his right, but
one of the goals of this project has always been to support standards
and I'm against using it to do just the opposite.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
Eric_Schwarzenbach@Classwell.com wrote:
>
> So you are against giving users the option because they might have
> Elliotte's opinion rather than yours, but at the same time you choose to
> end your rather interesting debate with Elliotte with an ad hominen
> attack rather than rebutting his arguments?
>
>
>
>
>
> *Arnaud Le Hors <le...@us.ibm.com>*
>
> 11/23/2003 08:58 PM
> Please respond to xerces-j-dev
>
>
> To: xerces-j-dev@xml.apache.org
> cc:
> Subject: Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
>
>
>
>
> Because I think it's wrong to let users limit their system to 1.0, so
> I'm against making this easy. All sorts of people misled by people like
> Elliotte will turn this on without understanding what it means.
> --
> Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
>
>
>
> Andy Clark wrote:
> > Arnaud Le Hors wrote:
> >
> >> Don't bother, I would veto applying such a patch. We need to
> >> facilitate and encourage adoption of XML 1.1, this is going against it.
> >
> >
> > Why? If there are Xerces users that want to use such
> > a feature, I see no reason not to include it. I would
> > still make the *default* be to accept XML 1.1 docs,
> > though.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Er...@Classwell.com.
So you are against giving users the option because they might have
Elliotte's opinion rather than yours, but at the same time you choose to
end your rather interesting debate with Elliotte with an ad hominen attack
rather than rebutting his arguments?
Arnaud Le Hors <le...@us.ibm.com>
11/23/2003 08:58 PM
Please respond to xerces-j-dev
To: xerces-j-dev@xml.apache.org
cc:
Subject: Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Because I think it's wrong to let users limit their system to 1.0, so
I'm against making this easy. All sorts of people misled by people like
Elliotte will turn this on without understanding what it means.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
Andy Clark wrote:
> Arnaud Le Hors wrote:
>
>> Don't bother, I would veto applying such a patch. We need to
>> facilitate and encourage adoption of XML 1.1, this is going against it.
>
>
> Why? If there are Xerces users that want to use such
> a feature, I see no reason not to include it. I would
> still make the *default* be to accept XML 1.1 docs,
> though.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Because I think it's wrong to let users limit their system to 1.0, so
I'm against making this easy. All sorts of people misled by people like
Elliotte will turn this on without understanding what it means.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
Andy Clark wrote:
> Arnaud Le Hors wrote:
>
>> Don't bother, I would veto applying such a patch. We need to
>> facilitate and encourage adoption of XML 1.1, this is going against it.
>
>
> Why? If there are Xerces users that want to use such
> a feature, I see no reason not to include it. I would
> still make the *default* be to accept XML 1.1 docs,
> though.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Andy Clark <an...@apache.org>.
Arnaud Le Hors wrote:
> Don't bother, I would veto applying such a patch. We need to facilitate
> and encourage adoption of XML 1.1, this is going against it.
Why? If there are Xerces users that want to use such
a feature, I see no reason not to include it. I would
still make the *default* be to accept XML 1.1 docs,
though.
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Don't bother, I would veto applying such a patch. We need to facilitate
and encourage adoption of XML 1.1, this is going against it.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
Elliotte Rusty Harold wrote:
> At 11:42 AM -0800 11/23/03, Davanum Srinivas wrote:
>
>> How about submitting a patch and a test case for
>> "http://apache.org/xml/features/allow-XML1.1"?
>> :)
>>
>
> If the Apache committers were seriously interested in this, I suspect I
> could write a test case. I'm not sure I know enough about the Xerces
> internals to write a decent patch for the code itself though. As I said,
> I'm very nervous about the code I wrote for my own use. But if it were
> decided that this was a good idea, then I guess I'd be willing to try.
> Somebody would have to give my code a thorough going over before
> committing it though.
>
> I do suspect that this would be better as a general SAX feature.
> Something like
>
> http://xml.org/sax/features/allow-XML1.1
>
> Xerces is hardly the only parser that's likely to need this, after all.
> I've cc'd the sax-devel list so we can get the relevant discussion going
> over there.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 11:42 AM -0800 11/23/03, Davanum Srinivas wrote:
>How about submitting a patch and a test case for
>"http://apache.org/xml/features/allow-XML1.1"?
>:)
>
If the Apache committers were seriously interested in this, I suspect
I could write a test case. I'm not sure I know enough about the
Xerces internals to write a decent patch for the code itself though.
As I said, I'm very nervous about the code I wrote for my own use.
But if it were decided that this was a good idea, then I guess I'd be
willing to try. Somebody would have to give my code a thorough going
over before committing it though.
I do suspect that this would be better as a general SAX feature. Something like
http://xml.org/sax/features/allow-XML1.1
Xerces is hardly the only parser that's likely to need this, after
all. I've cc'd the sax-devel list so we can get the relevant
discussion going over there.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Davanum Srinivas <di...@yahoo.com>.
How about submitting a patch and a test case for "http://apache.org/xml/features/allow-XML1.1"?
:)
-- dims
--- Elliotte Rusty Harold <el...@metalab.unc.edu> wrote:
> At 10:41 AM -0800 11/23/03, Andy Clark wrote:
>
>
> >I think you're being a little melodramatic, Elliotte. ;)
> >
> >As Michael stated, there is an easy mechanism to override
> >which parser configuration is used in Xerces by default.
> >And this would affect all Xerces instances in the JVM (or
> >custom class-loaded sandbox, if you want to use this
> >mechanism more than once in the same JVM), including the
> >parser instances created with JAXP.
>
> I have figured out how to do this. Thanks. However, I would not
> classify it as easy. It took several hours of wading through the
> Xerces source tree and experimentation to get it to work. Easy would
> be parser.setFeature("http://apache.org/xml/features/allow-XML1.1",
> false).
>
> A feature based solution would also make me feel more confident that
> this solution would continue to work in the future. Right now my code
> depends on about a dozen different protected and public methods in
> XNI, as well as suppositions about how, when, and why the
> XML11Configuration.parse(boolean complete) method is called, and
> which methods it should call in which order. I'm worried that some of
> this might change in the future in incompatible ways. I prefer
> working with pure SAX. Delving this deep into parser internals makes
> me very nervous.
> --
>
> Elliotte Rusty Harold
> elharo@metalab.unc.edu
> Effective XML (Addison-Wesley, 2003)
> http://www.cafeconleche.org/books/effectivexml
> http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 10:41 AM -0800 11/23/03, Andy Clark wrote:
>I think you're being a little melodramatic, Elliotte. ;)
>
>As Michael stated, there is an easy mechanism to override
>which parser configuration is used in Xerces by default.
>And this would affect all Xerces instances in the JVM (or
>custom class-loaded sandbox, if you want to use this
>mechanism more than once in the same JVM), including the
>parser instances created with JAXP.
I have figured out how to do this. Thanks. However, I would not
classify it as easy. It took several hours of wading through the
Xerces source tree and experimentation to get it to work. Easy would
be parser.setFeature("http://apache.org/xml/features/allow-XML1.1",
false).
A feature based solution would also make me feel more confident that
this solution would continue to work in the future. Right now my code
depends on about a dozen different protected and public methods in
XNI, as well as suppositions about how, when, and why the
XML11Configuration.parse(boolean complete) method is called, and
which methods it should call in which order. I'm worried that some of
this might change in the future in incompatible ways. I prefer
working with pure SAX. Delving this deep into parser internals makes
me very nervous.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Andy Clark <an...@apache.org>.
Elliotte Rusty Harold wrote:
> genuinely conformant parsers written in Java is very small. Up till now
> Xerces had been clearly the best. Possibly, if I don't find a better
> alternative, and if there's no simple way to turn Xerces into a
> conformant parser, then I will have to fork it. :-(
I think you're being a little melodramatic, Elliotte. ;)
As Michael stated, there is an easy mechanism to override
which parser configuration is used in Xerces by default.
And this would affect all Xerces instances in the JVM (or
custom class-loaded sandbox, if you want to use this
mechanism more than once in the same JVM), including the
parser instances created with JAXP.
I use the same mechanism in NekoHTML to swap out the
Xerces standard parser configuration with one capable of
parsing HTML. It's just an added Jar file that contains
the META-INF/services document queried by Xerces.
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 6:05 PM -0800 11/21/03, Arnaud Le Hors wrote:
>If somebody really wants this he/she can always have his/her own
>configuration I suppose. But I don't see any use case for this so I
>wouldn't spend resources on this.
>
The use case is interoperating with the vast installed base of
systems and software that expect and rely on XML 1.0 rules being
followed. I for one need and expect a parser to report all
well-formedness errors as required by XML 1.0. If Xerces cannot
easily be configured to do that, then I will have to consider using
another parser. Sadly the number of genuinely conformant parsers
written in Java is very small. Up till now Xerces had been clearly
the best. Possibly, if I don't find a better alternative, and if
there's no simple way to turn Xerces into a conformant parser, then I
will have to fork it. :-(
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Andy Clark wrote:
> However, it
> would be nice to have a setting that allows people
> to make Xerces strictly enforce a specific version
> over another.
>
If somebody really wants this he/she can always have his/her own
configuration I suppose. But I don't see any use case for this so I
wouldn't spend resources on this.
What might be useful is a convenience function that lets the user know
what version needs to be used. Ideally you'd like the implementation to
set it automatically for you but it requires walking through the whole
document which works for DOM but not for SAX.
The way I understand our current serializer work is that it lets the
user specify what version to output and if the document contains
characters that don't match an error is raised during serialization.
One strategy for the application that wants to handle all documents
would then be to try 1.0 first and on error re-try with 1.1. However, if
you're sending the bits on the wire as you serialize this can be
expensive or even damaging. So, applications may find cheaper to always
produce 1.1 documents. I guess it really depends on the application...
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Andy Clark <an...@apache.org>.
Arnaud Le Hors wrote:
> Not at all. Parsers should accept 1.0 and 1.1 without discrimination.
> It's on the serialization side that one should control whether to use
> 1.0 or 1.1. I would agree that people should only produce 1.1 documents
> when necessary. I'm told Xerces leaves it to the user to decide. That
> seems reasonable to me.
I agree with Arnaud on this point. However, it
would be nice to have a setting that allows people
to make Xerces strictly enforce a specific version
over another.
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Not at all. Parsers should accept 1.0 and 1.1 without discrimination.
It's on the serialization side that one should control whether to use
1.0 or 1.1. I would agree that people should only produce 1.1 documents
when necessary. I'm told Xerces leaves it to the user to decide. That
seems reasonable to me.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
Elliotte Rusty Harold wrote:
>
>> * Reimplemented XML11Configuration (the default configuration)
>
>
>
> What does this mean? Will Xerces 2.6 now accept XML 1.1 documents
> without any request from the user? This strikes me as a very bad idea.
> XML 1.1 has minimal use to a small number of users. Encouraging its use
> when its not explicitly desired or needed will reduce the compatibility
> and interoperability of XML.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
>* Reimplemented XML11Configuration (the default configuration)
What does this mean? Will Xerces 2.6 now accept XML 1.1 documents
without any request from the user? This strikes me as a very bad
idea. XML 1.1 has minimal use to a small number of users. Encouraging
its use when its not explicitly desired or needed will reduce the
compatibility and interoperability of XML.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [ANNOUNCEMENT]: Xerces-J 2.6.0 now available
Posted by Andy Clark <an...@apache.org>.
Elena Litani wrote:
> The Xerces-J team is very happy to announce that version 2.6.0 of
> Xerces-J is now available.
Great job, everyone! This release has a lot of
great additions and fixes included for users. :)
I've submitted the new release announcement to
Freshmeat so it should be up sometime today. To
ease the load on our own servers, I entered the
mirror URLs for the binary download.
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org