https://issues.apache.org/bugzilla/show_bug.cgi?id=48194

Robert Streich <robert.streich@objectfx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robert.streich@objectfx.com

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=48194

--- Comment #2 from Robert Streich <robert.streich@objectfx.com> 2009-11-16 10:13:18
UTC ---
Created an attachment (id=24543)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24543)
Simple set up with included/imported schemas to illustrate bug.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=48194

--- Comment #1 from Robert Streich <robert.streich@objectfx.com> 2009-11-13 14:47:52
UTC ---
I don't know if this is viable, but this works:

        // The namespace is useful for resolving namespace aware
        // grammars such as XML schema. Let it take precedence over
        // the external identifier if one exists.
        String namespace = resourceIdentifier.getNamespace();
        if (namespace != null) {
           if (resourceIdentifier instanceof XSDDescription
                 && XSDDescription.CONTEXT_INCLUDE == ((XSDDescription)
resourceIdentifier).getContextType()) {
              resolvedId =
resolveSystem(resourceIdentifier.getLiteralSystemId());
           } else {
            resolvedId = resolveURI(namespace);
           }
        }

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=48194

           Summary: Xml Catalog Resovler fails with included schemas
           Product: XmlCommons
           Version: 1.x
          Platform: PC
        OS/Version: Windows Vista
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Resolver
        AssignedTo: commons-dev@xml.apache.org
        ReportedBy: robert.streich@objectfx.com


If you attempt to include a schema into one that has a targetNamespace,
it fails to correctly resolve the included component. The problem is
with line ~420 of XMLCatalogResolver:

        // The namespace is useful for resolving namespace aware
        // grammars such as XML schema. Let it take precedence over
        // the external identifier if one exists.
        String namespace = resourceIdentifier.getNamespace();
        if (namespace != null) {
            resolvedId = resolveURI(namespace);
        }

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable



Hi all,

The November board meeting is coming up on the 18th and we're due to
report. The Wiki page for the report is set up here:
http://wiki.apache.org/xerces/November2009. As usual I'll cover Xerces-=
J
and XML Commons. Could other committers please fill in the status for
Xerces-C and Xerces-P.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org=

I did some research to find the ASF projects that
manage their websites with Apache Forrest, and am
sending similar email to each project's dev mail list.
Already sent to general at xerces and general at xml,
but duplicates will not hurt.

The purposes of this email are to remind people
about some of the useful facilities of Forrest,
and also alert them to discussion about the status
and future directions of Forrest, and to appeal for
people to assist Forrest.

--- oOo ---

These are useful facilities to assist with developing
and managing a Forrest solution for your project's website.

"How to deploy documentation with the Forrestbot
svn workstage"
This explains how the Forrest project manages our
own documentation.
http://forrest.apache.org/howto-forrestbot-svn.html

"Generate an ASF mirrors page using interactive web form"
http://forrest.apache.org/docs/dev/howto/howto-asf-mirror.html

"ForrestBar - Firefox toolbar to ease navigation
and search of Forrest resources"
http://forrest.apache.org/tools/forrestbar.html

"How to do development with Apache Forrest"
http://forrest.apache.org/howto-dev.html

"Frequently Asked Questions"
http://forrest.apache.org/faq.html

"The Anakia output plugin"
This was developed to assist the old Incubator
website to stop using Forrest and export all content
to an Anakia "xdoc" format. From there it could used
by an Anakia-based build system, or be further transformed.
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.Anakia/

As usual, if you need further assistance with anything
then please ask on the Forrest mail lists.

--- oOo ---

There is discussion currently underway on the Forrest
dev mail list about the current status and future
direction of Forrest.
http://thread.gmane.org/gmane.text.xml.forrest.devel/27325

If anyone can assist Forrest, in any capacity, then
please do.

-David

Content-type: text/plain; charset=US-ASCII

Jack,

Jack Bates <ms419@freezone.co.uk> wrote on 10/28/2009 07:48:23 PM:

> On Sat, 2009-10-24 at 15:10 -0400, Michael Glavassevich wrote:
> > The OASIS catalog DTD is included in resolver.jar and there is a
> > BootstrapResolver [1] which gets installed on the parser that reads
> > the catalog which can return this DTD. I'm sure the reason that isn't
> > happening is that the public and system IDs differ from the ones that
> > the resolver knows about. You're supposed to extend BootstrapResolver
> > (in your own application) if you need support for more than the
> > well-known public IDs and URIs for the catalog DTDs / schemas and set
> > an instance of this extension on the CatalogManager [2].
>
> Thank you Michael! After some more digging, I think the reason that the
> w3c-dtd-xhtml catalog.xml isn't using the well known catalog DTD public
> ID and URI,
>
> <!DOCTYPE catalog PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN"
>   "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
>
> is that it's trying to use a different DTD?
>
> <!DOCTYPE catalog PUBLIC "-//GlobalTransCorp//DTD XML Catalogs V1.0-
> Based Extension V1.0//EN"
>     "http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd">
>
> The xml-core package distributes "tr9401.dtd", in addition to
> "catalog.dtd" - here it is,
> http://www.sfu.ca/~jdbates/tmp/debian/200910280/tr9401.dtd
>
> - and here are the differences between it, and the "catalog.dtd"
> included in resolver.jar,
> http://www.sfu.ca/~jdbates/tmp/debian/200910280/diff
>
> I dunno if the w3c-dtd-xhtml catalog.xml actually requires this
> different DTD, but it sounds like if it does, and the system ID isn't
> accessible, then it will only be parsable by tools which extend
> BootstrapResolver to add support for this different DTD?

That's what I would do. I could imagine extending BootstrapResolver so that
it uses a secondary catalog resolver so that you just update a catalog file
instead of the code when you need a redirect for yet another catalog DTD.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

On Sat, 2009-10-24 at 15:10 -0400, Michael Glavassevich wrote:
> The OASIS catalog DTD is included in resolver.jar and there is a
> BootstrapResolver [1] which gets installed on the parser that reads
> the catalog which can return this DTD. I'm sure the reason that isn't
> happening is that the public and system IDs differ from the ones that
> the resolver knows about. You're supposed to extend BootstrapResolver
> (in your own application) if you need support for more than the
> well-known public IDs and URIs for the catalog DTDs / schemas and set
> an instance of this extension on the CatalogManager [2].

Thank you Michael! After some more digging, I think the reason that the
w3c-dtd-xhtml catalog.xml isn't using the well known catalog DTD public
ID and URI,

<!DOCTYPE catalog PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN" 
  "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">

is that it's trying to use a different DTD?

<!DOCTYPE catalog PUBLIC "-//GlobalTransCorp//DTD XML Catalogs V1.0-Based Extension V1.0//EN"
    "http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd">

The xml-core package distributes "tr9401.dtd", in addition to
"catalog.dtd" - here it is,
http://www.sfu.ca/~jdbates/tmp/debian/200910280/tr9401.dtd

- and here are the differences between it, and the "catalog.dtd"
included in resolver.jar,
http://www.sfu.ca/~jdbates/tmp/debian/200910280/diff

I dunno if the w3c-dtd-xhtml catalog.xml actually requires this
different DTD, but it sounds like if it does, and the system ID isn't
accessible, then it will only be parsable by tools which extend
BootstrapResolver to add support for this different DTD?

Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable


The OASIS catalog DTD is included in resolver.jar and there is a
BootstrapResolver [1] which gets installed on the parser that reads the=

catalog which can return this DTD. I'm sure the reason that isn't happe=
ning
is that the public and system IDs differ from the ones that the resolve=
r
knows about. You're supposed to extend BootstrapResolver (in your own
application) if you need support for more than the well-known public ID=
s
and URIs for the catalog DTDs / schemas and set an instance of this
extension on the CatalogManager [2].

Thanks.

[1]
http://xml.apache.org/commons/components/apidocs/resolver/org/apache/xm=
l/resolver/helpers/BootstrapResolver.html
[2]
http://xml.apache.org/commons/components/apidocs/resolver/org/apache/xm=
l/resolver/CatalogManager.html#setBootstrapResolver
(org.apache.xml.resolver.helpers.BootstrapResolver)

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Earl Hood <earl@earlhood.com> wrote on 10/24/2009 01:22:50 PM:

> On October 23, 2009 at 17:19, someone wrote:
>
> > Here's an example of a catalog.xml file distributed in the Debian a=
nd
> > Ubuntu w3c-dtd-xhtml package,
> > http://www.sfu.ca/~jdbates/tmp/debian/200910230/catalog.xml
> >
> > It starts with,
> >
> > <?xml version=3D'1.0'?>
> > <!DOCTYPE catalog PUBLIC "-//GlobalTransCorp//DTD XML Catalogs
V1.0-Based
> > <Extension V1.0//EN"
> >     "http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd";>
> > [...]
>
> I think they should fix it so the system identifier is set
> to a pathname on the local file system.
>
> Also, the public identifier used is not the standard public
> identifier, "-//OASIS//DTD XML Catalogs V1.1//EN".  So even
> if the resolver provided intrinsic recognition of
> the "-//OASIS//DTD XML Catalogs V1.1//EN" identifier, it
> would still be of no use in this case.
>
> One can argue that the w3c-dtd-xhtml package has a bug in
> their distribution since it provides no facility to resolve
> the DTD to the local file system.  The system identifier
> should be set to the pathname the catalog DTD is placed
> by the w3c-dtd-xhtml installer.
>
> > I understand comment #4,
> > https://bugs.launchpad.net/ubuntu/+source/w3c-dtd-
> xhtml/+bug/400259/comments/4
> >
> > - to be suggesting that org.apache.xml.resolver is not following th=
e
> > encouragement of,
> > http://www.oasis-open.org/committees/download.php/14809/xml-
> catalogs.html#s.bootstrap
> >
> > "Implementations are encouraged to provide some sort of bootstrappi=
ng
> > functionality to resolve external identifiers and URIs that the
> > implementation needs to load catalog entry files.
>
> It is not a requirement:
>
>   Conformant processors are not required to be able to perform
>   resolution of those identifiers through the XML Catalog.
>
> The word "should" is used in other text instead of "must".  Also,
> the following is stated:
>
>   Users can avoid any problems that might arise by limiting the
>   external identifiers and URIs used to those that do not need
>   resolution. Note that this only applies to external identifiers and=

>   URIs that must be resolved in order to load the catalog entry file.=

>
> > - and to be suggesting that not following this encouragement is a b=
ug
> >
> > Is maybe my understanding wrong - or either of these suggestions wr=
ong?
>
> The recommendations of the Oasis document are beneficial, but
> they are only recommendations, not requirements.  So the "bug"
> reports are really enhancement requests.
>
> IMO, the work-around for the problem is easy, and is directly
> suggested by the Oasis document: Use system identifiers that
> are resolvable without the need of a catalog.
>
> I think the underlying technical problem of why the resolver library
> does not provide intrinsic resolution of the catalog DTD is that
> the library does not know where the DTD may be installed for any
> system that uses the resolver.  Since other software systems include
> the resolver in their distribution, the DTD itself may not even
> be available.
>
> A possible method of always knowing how to find the catalog DTD is
> for the resolver to include the DTD in the resolver.jar file itself.
> The resolver could register a custom (internal) resolver to the XML
> parser when reading catalog files so any references to the DTD can
> be resolved via a classpath resource lookup.  IMO, I'm not sure it
> is worth the effort to do this when simple work-arounds exist for
> the problem.
>
> I'm sure patches are welcome if anyone wants to implement this
> functionality.
>
> --ewh=

On October 23, 2009 at 17:19, someone wrote:

> Here's an example of a catalog.xml file distributed in the Debian and
> Ubuntu w3c-dtd-xhtml package,
> http://www.sfu.ca/~jdbates/tmp/debian/200910230/catalog.xml
> 
> It starts with,
> 
> <?xml version='1.0'?>
> <!DOCTYPE catalog PUBLIC "-//GlobalTransCorp//DTD XML Catalogs V1.0-Based 
> <Extension V1.0//EN"
>     "http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd";>
> [...]

I think they should fix it so the system identifier is set
to a pathname on the local file system.

Also, the public identifier used is not the standard public
identifier, "-//OASIS//DTD XML Catalogs V1.1//EN".  So even
if the resolver provided intrinsic recognition of
the "-//OASIS//DTD XML Catalogs V1.1//EN" identifier, it
would still be of no use in this case.

One can argue that the w3c-dtd-xhtml package has a bug in
their distribution since it provides no facility to resolve
the DTD to the local file system.  The system identifier
should be set to the pathname the catalog DTD is placed
by the w3c-dtd-xhtml installer.

> I understand comment #4,
> https://bugs.launchpad.net/ubuntu/+source/w3c-dtd-xhtml/+bug/400259/comments/4
> 
> - to be suggesting that org.apache.xml.resolver is not following the
> encouragement of,
> http://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html#s.bootstrap
> 
> "Implementations are encouraged to provide some sort of bootstrapping
> functionality to resolve external identifiers and URIs that the
> implementation needs to load catalog entry files.

It is not a requirement:

  Conformant processors are not required to be able to perform
  resolution of those identifiers through the XML Catalog.

The word "should" is used in other text instead of "must".  Also,
the following is stated:

  Users can avoid any problems that might arise by limiting the
  external identifiers and URIs used to those that do not need
  resolution. Note that this only applies to external identifiers and
  URIs that must be resolved in order to load the catalog entry file.

> - and to be suggesting that not following this encouragement is a bug
> 
> Is maybe my understanding wrong - or either of these suggestions wrong?

The recommendations of the Oasis document are beneficial, but
they are only recommendations, not requirements.  So the "bug"
reports are really enhancement requests.

IMO, the work-around for the problem is easy, and is directly
suggested by the Oasis document: Use system identifiers that
are resolvable without the need of a catalog.

I think the underlying technical problem of why the resolver library
does not provide intrinsic resolution of the catalog DTD is that
the library does not know where the DTD may be installed for any
system that uses the resolver.  Since other software systems include
the resolver in their distribution, the DTD itself may not even
be available.

A possible method of always knowing how to find the catalog DTD is
for the resolver to include the DTD in the resolver.jar file itself.
The resolver could register a custom (internal) resolver to the XML
parser when reading catalog files so any references to the DTD can
be resolved via a classpath resource lookup.  IMO, I'm not sure it
is worth the effort to do this when simple work-arounds exist for
the problem.

I'm sure patches are welcome if anyone wants to implement this
functionality.

--ewh

On October 23, 2009 at 09:52, Jack Bates wrote:

> I'm getting the following exception using the XML catalog resolver with
> FOP,

> DELEGATE_PUBLIC: -//W3C//DTD XHTML//EN
>         file:/usr/share/xml/xhtml/schema/dtd/catalog.xml
> resolvePublic(-//W3C//DTD XHTML 1.0 Transitional//EN,null)
> Switching to delegated catalog(s):
>         file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
> Parse catalog: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
> Loading catalog: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
> Default BASE: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
> 22-Oct-2009 5:04:13 PM org.apache.fop.cli.Main startFOP
> SEVERE: Exception
> javax.xml.transform.TransformerException: java.net.UnknownHostException: 
> globaltranscorp.org

Is globaltranscorp.org resolvable on the system you are running FOP?
Apparently the underlying network library of the JVM cannot resolve
the hostname.

As for the "resolve external entities" problem, it appears to
be a chicken-n-egg problem.  The resolver depends on the underlying
XML parser to parse the XML catalog file, but at that time,
the base entity resolution of the XML parser is being used since
the resolver is still bootstrapping itself.

If your catalog file contains a DOCTYPE declaration with a public and
system identifier, then the XML parser will try to resolve it, and if
the system identifier listed is not accessible, you will get an error.

All of this is a function of the XML parser itself and NOT the
resolver library.

In practice, I normally do not specify a doctype declaration for
catalog files to avoid the unnecessary overhead of parsing a DTD.

If you absolutely need to have DTD validation of your catalog files,
make sure the system identifier is resolvable, and preferably to a
location on the local file system for better performance and to avoid
dependency on a remote system.

--ewh

I'm getting the following exception using the XML catalog resolver with
FOP,

[...]
DELEGATE_PUBLIC: -//W3C//DTD XHTML//EN
        file:/usr/share/xml/xhtml/schema/dtd/catalog.xml
resolvePublic(-//W3C//DTD XHTML 1.0 Transitional//EN,null)
Switching to delegated catalog(s):
        file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
Parse catalog: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
Loading catalog: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
Default BASE: file:/usr/share/xml/xhtml/schema/dtd/1.0/catalog.xml
22-Oct-2009 5:04:13 PM org.apache.fop.cli.Main startFOP
SEVERE: Exception
javax.xml.transform.TransformerException: java.net.UnknownHostException: globaltranscorp.org
        at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:314)
        at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:146)
        at org.apache.fop.cli.Main.startFOP(Main.java:174)
        at org.apache.fop.cli.Main.main(Main.java:205)
[...]

I think it's the same issue reported here,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491091

- and here,
https://bugs.launchpad.net/ubuntu/+source/w3c-dtd-xhtml/+bug/400259

Is comment #4 correct?

"Arguably this is a bug in org.apache.xml.resolver, cf.
http://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html#s.bootstrap - the
resolver should be able to parse catalog files without needing to resolve external entities"

https://bugs.launchpad.net/ubuntu/+source/w3c-dtd-xhtml/+bug/400259/comments/4

After stumbling upon this answer I thought I'd do the conversion and compare
the two approaches. 

I happened to have used the original posters method but didn't like it
because it seemed to move the persistence meta-data out of the model and
into an external adapter. Some people may like that, but I prefer to have
the persistence meta-data in the form of annotations right next to the model
(or DTO if you prefer). 

So I made the conversion and using XStream I was able to remove vast tracts
of marshalling code and condense it into a a single 3 line templated method
in a base class. All the mapping information is now held in simple to
understand annotations, and specialised date handling is managed through an
XStream converter. 

Now for the all important performance figures. In my particular
configuration that requires a *lot* of XML parsing and mucking about with
various InputStreams, XStream came out on top - which is a relief given the
benefits that it brings. The times to completion were: 

Traditional XML through DocumentFactory and Node analysis=32s
XStream=26s

Not a vast difference (~20%) but enough to justify XStream as the better way
to go.

Hope this helps someone.

Gary  


Bruno Borges wrote:
> 
> Try XStream. :-)
> 
> Cheers,
> Bruno
> 

-- 
View this message in context: http://www.nabble.com/Proposal---A-Very-Simple-API-for-Reading-Simple-XML-Data-tp23804602p25344422.html
Sent from the Apache XML - Commons - Dev mailing list archive at Nabble.com.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47720

           Summary: Find Catalogs using Service Provider Interface
           Product: XmlCommons
           Version: 1.x
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Resolver
        AssignedTo: commons-dev@xml.apache.org
        ReportedBy: Martin.vGagern@gmx.net


--- Comment #0 from Martin von Gagern <Martin.vGagern@gmx.net> 2009-08-21 03:00:04 PDT
---
Developing apps would be greatly simplified if you could simply add some JAR to
the classpath, and a Catalog as generated by the default CatalogManager would
find the catalog within that JAR as well as the documents it references.

To achieve this, I believe a slightly modified version of the Service Provider
Interface would be most suitable.
http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
describes that a file under META-INF/services/package.interface.Name should
list qualified names of classes providing said interface.

To work with XML catalogs, you would specify a class name, but instead the name
of a resource. So I think that you should have a file called
"META-INF/services/org.apache.xml.resolver.catalog" which would contain lines
like "my/company/catalog.xml". That catalog could then be located as a
resource, auto-appended to the list of catalogs and parsed along with the
system catalogs.

One could consider placing the catalog itself in the META-INF directory. That,
however, would probably prevent it from being uniquely identified by its name
alone, which might be useful if you want to deal with the catalog yourself,
without using the full CatalogManager framework.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable



Hey all,

According to the calendar the August board meeting is happening this
Wednesday and we're due to report again.  The page for the report is se=
tup
on the Wiki here: http://wiki.apache.org/xerces/August2009.  As usual I=
'll
cover Xerces-J and XML Commons.  Could other committers please fill in =
the
status for Xerces-C and Xerces-P.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org=

https://issues.apache.org/bugzilla/show_bug.cgi?id=47671



--- Comment #3 from Earl Hood <earl@earlhood.com> 2009-08-11 08:00:03 PDT ---
(In reply to comment #2)
> resolveSystem(file:/files/erlang/module.xsl)
> resolveSystem(file:/files/erlang/erlang.xml)
> resolveSystem(file:/files/erlang/erlref.dtd)

The above verbosity implies (to me) that the parser is passing
the wrong system ID to the resolver.

I.e. Instead of the XML parser passing just "erlref.dtd" to
the resolver, the parser is first fully qualifying the system ID
(probably based upon the current working directory)
before it passes the system ID to the resolver.  Since the
catalog has no entry for "file:/files/erlang/erlref.dtd", the
resolver will find no matching entries.

The parser then attempts to load the file directory, which of
course fails since the file does not exist with given path.

At this time, this appears to be an XML parser problem.
The parser should only be passing "erlref.dtd" to the
resolver.

BTW, did you trim some of the diagnostic output?  It seems
the XML parser is calling Catalog directly versus the
CatalogResolver class that implements the SAX EntityResolver
and JAXP URIResolver interfances.  I see no debugging messages
from the CatalogResolver class.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47671



--- Comment #2 from Dave Pawson <dave.pawson@gmail.com> 2009-08-10 21:53:34 PDT ---
What is the full catalog?
Does the path "/files/erlang/dtds/erlref.dtd" exist on
the filesystem?  Or have you set xml:base?

Have you tried setting the verbosity with the
xml.catalog.verbosity property. Set to 5 or larger to get maximum
verbosity.  This will determine if your catalog is actually getting
read and what the resolver does when resolving a uri.

What is the exact error message(s) you get?

If you can provide a reproducable test case, it will make
finding a solution faster.

1. full catalog

<?xml version="1.0" encoding="utf-8"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
     >
 <system
      systemId="erlref.dtd"
      uri="/files/erlang/dtds/erlref.dtd"            />
 <systemSuffix
      systemIdSuffix="xhtml-lat1.ent"
      uri="/files/erlang/dtds/xhtml-lat1.ent"     />
</catalog>

2. The dtd and entity file are in ./dtds /files/erlang/dtds
3. I had tried xml:base, but now removed.

Instance has 
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd">
a file of 
<erlref>&nbsp</erlref>

would test it.

I have CatalogManger.properties with verbosity set high.

Error reported is:

Parse catalog: erlang.catalog.xml                            
Loading catalog: erlang.catalog.xml
Default BASE: file:////files/erlang/erlang.catalog.xml
system: erlref.dtd
        /files/erlang/dtds/erlref.dtd
SYSTEM: erlref.dtd
        file:/files/erlang/dtds/erlref.dtd
systemSuffix: xhtml-lat1.ent
        /files/erlang/dtds/xhtml-lat1.ent
SYSTEM_SUFFIX: xhtml-lat1.ent
        file:/files/erlang/dtds/xhtml-lat1.ent
resolveSystem(file:/files/erlang/module.xsl)
resolveSystem(file:/files/erlang/erlang.xml)
resolveSystem(file:/files/erlang/erlref.dtd)
Error on line 2 column 37 of file:/files/erlang/erlang.xml:
  Error reported by XML parser: Cannot read from file:/files/erlang/erlref.dtd
(/files/erlang/erlref.dtd (No such file or directory))
Transformation failed: Run-time errors were reported

HTH

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47671


Earl Hood <earl@earlhood.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |earl@earlhood.com


--- Comment #1 from Earl Hood <earl@earlhood.com> 2009-08-10 16:27:31 PDT ---
What is the full catalog?
Does the path "/files/erlang/dtds/erlref.dtd" exist on
the filesystem?  Or have you set xml:base?

Have you tried setting the verbosity with the
xml.catalog.verbosity property. Set to 5 or larger to get maximum
verbosity.  This will determine if your catalog is actually getting
read and what the resolver does when resolving a uri.

What is the exact error message(s) you get?

If you can provide a reproducable test case, it will make
finding a solution faster.

BTW, I'm not an official maintainer of the resolver code,
but I had to dive into it over a year ago to fix bugs.
I believe some of my patches have been accepted, but
I do not think a new release of the resolver has been
done in quite some time.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47671

           Summary: unable to resolve a relative path
           Product: XmlCommons
           Version: 1.x
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Resolver
        AssignedTo: commons-dev@xml.apache.org
        ReportedBy: dave.pawson@gmail.com


--- Comment #0 from Dave Pawson <dave.pawson@gmail.com> 2009-08-10 11:32:00 PDT ---
catalog entry of

 <system
      systemId="erlref.dtd"
      uri="/files/erlang/dtds/erlref.dtd"

     />

Is never seen by the resolver. See
http://www.sagehill.net/docbookxsl/WriteCatalog.html#ResolveDtdLoc


Yet http://xmlsoft.org/XSLT/xsltproc.html  catalog resolves this?

I.e. I think it should resolve appropriately

Marked as XSLTBug, since transform cannot take place
without DTD resolution


regards DaveP

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Content-type: text/plain; charset=US-ASCII


Forwarding on behalf of the ApacheCon US 2009 Team.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Sally Khudairi <sk@apache.org> wrote on 08/07/2009 09:55:10 PM:

> Sign up for ApacheCon US by 14 August and save up to $500!
>
> This year's ApacheCon US promises to deliver our most extensive
> program to date, and largest anticipated gathering of the global
> Apache community to celebrate the ASF's milestone 10th Anniversary.
> The San Francisco Bay Area is where the very first ASF official user
> conference was held, and we hope that you will join us in
> celebrating the ASF's success!
>
> Apache members, code contributors, users, developers, system
> administrators, business managers, service providers, and vendors
> will convene 2-6 November in Oakland, California, for a week of
> training, presentations, sharing and hacking. ApacheCon US 2009
> features new content tracks, MeetUps, and GetTogethers, as well as a
> number of events open to the public free of charge, such as the
> Hackathon and 2-day BarCampApache, in appreciation of their support
> over the past decade.
>
> Be sure to register by 14 August to save up to $500! To sign up, visit
> http://www.us.apachecon.com/
>
> Those wishing to attend ApacheCon, but may be unable to do so due to
> financial reasons are encouraged to apply for Travel Assistance by
> completing the form at http://www.apache.org/travel/ Financial
> support for flights, accommodation, subsistence, and conference fees
> are availablAnyone involved in Open Source is welcome to apply for
> financial support for flights, accommodation, subsistence and
> Conference fees. Hurry, applications close on 17 August.
>
> Conference sponsor, exhibitor, and community partnerships are also
> available: please contact Delia Frees at delia@apachecon.com for details.
>
> # # #

https://issues.apache.org/bugzilla/show_bug.cgi?id=45207


Florent Georges <fgeorges@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fgeorges@gmail.com




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Content-type: text/plain; charset=US-ASCII


(Apologies if you're receiving this a 2nd time. It seems most of the lists
didn't get the first note.)

Forwarding on behalf of the ASF's Travel Assistance Committee.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

"Gav..." <gmcdonald@apache.org> wrote on 07/22/2009 05:46:15 AM:

> The Travel Assistance Committee is taking in applications for those
wanting
> to attend ApacheCon US 2009 (Oakland) which takes place between the 2nd
and
> 6th November 2009.
>
> The Travel Assistance Committee is looking for people who would like to
be
> able to attend ApacheCon US 2009 who may need some financial support in
> order to get there. There are limited places available, and all
applications
> will be scored on their individual merit. Applications are open to all
open
> source developers who feel that their attendance would benefit
themselves,
> their project(s), the ASF and open source in general.
>
> Financial assistance is available for flights, accommodation, subsistence
> and Conference fees either in full or in part, depending on
circumstances.
> It is intended that all our ApacheCon events are covered, so it may be
> prudent for those in Europe and/or Asia to wait until an event closer to
> them comes up - you are all welcome to apply for ApacheCon US of course,
but
> there should be compelling reasons for you to attend an event further
away
> that your home location for your application to be considered above those
> closer to the event location.
>
> More information can be found on the main Apache website at
> http://www.apache.org/travel/index.html - where you will also find a link
to
> the online application and details for submitting.
>
> Applications for applying for travel assistance will open on 27th July
2009
> and close of the 17th August 2009.
>
> Good luck to all those that will apply.
>
> Regards,
>
> The Travel Assistance Committee
> --------------------

Try XStream. :-)

Cheers,
Bruno


Hi Jake,

Thanks for pointing that out - I didn't know about that.

First impressions are that yes it's [very] flexible, my only criticisms
being that it doesn't use generics, and that it's a pretty big API, whereas
the single-class solution is nice and light weight and probably caters for
the majority of use cases.

Anyway, whether that warrants another interface is questionable... probably
not.

Cheers,
Chris.


Jacob Kjome wrote:
> 
> Have you considered commons-configuration [1]?  It seems to me it does
> what 
> you want, while being very flexible and robust.
> 
> 
> [1] http://commons.apache.org/configuration/
> 
> Jake
> 
> 
> 


-----
Bruno Borges
blog.brunoborges.com.br
+55 21 76727099

"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
-- 
View this message in context: http://www.nabble.com/Proposal---A-Very-Simple-API-for-Reading-Simple-XML-Data-tp23804602p24606592.html
Sent from the Apache XML - Commons - Dev mailing list archive at Nabble.com.

https://issues.apache.org/bugzilla/show_bug.cgi?id=15647


Mark Thomas <markt@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
         AssignedTo|curcuru@apache.org          |commons-dev@xml.apache.org




--- Comment #2 from Mark Thomas <markt@apache.org>  2009-06-10 13:26:47 PST ---
Reset assignee so mails go to list.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=4989


Mark Thomas <markt@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
         AssignedTo|edwingo@apache.org          |commons-dev@xml.apache.org




--- Comment #2 from Mark Thomas <markt@apache.org>  2009-06-10 13:26:23 PST ---
Reset assignee so mails go to list.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47334

           Summary: Behaviour for null/default namespace unspecified;
                    NPE's for null publicId.
           Product: XmlCommons
           Version: 1.x
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Resolver
        AssignedTo: commons-dev@xml.apache.org
        ReportedBy: cps@decisionsoft.com


Created an attachment (id=23777)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23777)
Test case showing the NPE.

When using the resolvePublic method for a schema with the null namespace, or an
attribute in the default namespace, this method is likely to be called.

DOM uses 'null' for this namespace whereas JAXP tends to use the empty string
(see javax.xml.XMLConstants.NULL_NS_URI) so the javadoc should specify which is
used in the resolver internals.

The code has lots of null checks in this method which makes me think you expect
null to be passed in and yet this null pointers as seen in the attached test
case.


I can't vouch for whether or not the resolver behaves sensibly when the
publicId is empty string.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Hi Jake,

Thanks for pointing that out - I didn't know about that.

First impressions are that yes it's [very] flexible, my only criticisms
being that it doesn't use generics, and that it's a pretty big API, whereas
the single-class solution is nice and light weight and probably caters for
the majority of use cases.

Anyway, whether that warrants another interface is questionable... probably
not.

Cheers,
Chris.


Have you considered commons-configuration [1]?  It seems to me it does what 
you want, while being very flexible and robust.


[1] http://commons.apache.org/configuration/

Jake


-- 
View this message in context: http://www.nabble.com/Proposal---A-Very-Simple-API-for-Reading-Simple-XML-Data-tp23804602p23823138.html
Sent from the Apache XML - Commons - Dev mailing list archive at Nabble.com.

Have you considered commons-configuration [1]?  It seems to me it does what 
you want, while being very flexible and robust.


[1] http://commons.apache.org/configuration/

Jake

On Sun, 31 May 2009 09:24:48 -0700 (PDT)
  chris0 <technical0@gmail.com> wrote:
> 
> Hello,
> 
> I'm making this proposal because I couldn't find a good solution to a
> problem that I recently had.
> 
> What I wanted to do was to configure an application with a simple XML file,
> something along the lines of:
> 
> <config>
> 	<title>test</title>
> 	<version
> 		major="1"
> 		minor="2"/>
> 	<roles>
> 		<role name="admin"/>
> 		<role name="user"/>
> 	</roles>
> 	<users>
> 		<user name="joe" password="pass" role="admin"/>
> 		<user name="harry" password="secret" role="user"/>
> 	</users>
> </config>
> 
> So the point is that it's really a very simple bit of XML data and what I
> wanted was a nice easy way to read it in. The current options seem to be
> SAX, DOM or JAXB.
> 
> To use JAXB I need an XSD which is just complicating things too much for a
> simple config file. SAX is a bit low-level and complicated too. The best
> option is probably DOM, but even DOM is quite verbose. Infact DOM is verbose
> enough that it made me think for a while if I could just use some other
> mechanism such as a properties file so that I didn't have to bother with
> DOM.
> 
>For the purpose of this proposal I've written what I think is pretty much
> the most concise way to parse this data with DOM. Also note that I want to
> provide some basic error reporting if the XML data is not in the expected
> format. The code follows below:
> 
> 	FileInputStream fileInputStream = null;
> 	try
> 	{
> 		String rootName = "config";
> 		fileInputStream = new FileInputStream("config.xml");		
> 		DocumentBuilderFactory builderFactory =
> DocumentBuilderFactory.newInstance();
> 		DocumentBuilder builder = builderFactory.newDocumentBuilder();
> 		Document document = builder.parse(fileInputStream);
> 		Element rootElement = document.getDocumentElement();
> 		if(!rootElement.getNodeName().equals(rootName)) 
> 			throw new Exception("Could not find root node: "+rootName);
> 
> 		NodeList titles = rootElement.getElementsByTagName("title");
> 		if(titles.getLength()!=1) throw new Exception("Could not find individual
> node: title");
> 		Node title = titles.item(0);
> 		out.println("title: "+title.getTextContent());
> 		
> 		NodeList versions = rootElement.getElementsByTagName("version");
> 		if(versions.getLength()!=1) throw new Exception("Could not find individual
> node: version");
> 		Node version = versions.item(0);
> 		NamedNodeMap versionAttributes = version.getAttributes();
> 		Node major = versionAttributes.getNamedItem("major");
> 		if(major==null) throw new Exception("Could not find attribute: major");
> 		Node minor = versionAttributes.getNamedItem("minor");
> 		if(minor==null) throw new Exception("Could not find attribute: minor");
> 		out.println(
> 			"version:
> "+Integer.parseInt(major.getNodeValue())+"."+Integer.parseInt(minor.getNodeValue()));
> 		
> 		NodeList roles = rootElement.getElementsByTagName("roles");
> 		if(roles.getLength()!=1) throw new Exception("Could not find individual
> node: roles");
> 		
> 		NodeList roleList = ((Element)roles.item(0)).getElementsByTagName("role");
> 		int n = roleList.getLength();
> 		for(int i=0;i<n;i++)
> 		{
> 			Node role = roleList.item(i);
> 			Node roleName = role.getAttributes().getNamedItem("name");
> 			if(roleName==null) throw new Exception("Could not find attribute: name");
> 			out.println("role: name: "+roleName.getNodeValue());
> 		}
> 		
> 		NodeList users = rootElement.getElementsByTagName("users");
> 		if(users.getLength()!=1) throw new Exception("Could not find individual
> node: users");
> 		
> 		NodeList userList = ((Element)users.item(0)).getElementsByTagName("user");
> 		n = userList.getLength();
> 		for(int i=0;i<n;i++)
> 		{
> 			Node user = userList.item(i);
> 			NamedNodeMap userAttributes = user.getAttributes();
> 			Node userName = userAttributes.getNamedItem("name");
> 			if(userName==null) throw new Exception("Could not find attribute: name");
> 			Node userPassword = userAttributes.getNamedItem("password");
> 			if(userPassword==null) throw new Exception("Could not find attribute:
> password");
> 			Node userRole = userAttributes.getNamedItem("role");
> 			if(userPassword==null) throw new Exception("Could not find attribute:
> role");
> 			out.println(
> 				"user: name: "+userName.getNodeValue()+
> 				", password: "+userPassword.getNodeValue()+
> 				", role: "+userRole.getNodeValue());
> 		}
> 	}
> 	finally
> 	{
> 		if(fileInputStream!=null) fileInputStream.close();
> 	}
> 	
> Output:
> 
> 	title: test
> 	version: 1.2
> 	role: name: admin
> 	role: name: user
> 	user: name: joe, password: pass, role: admin
> 	user: name: harry, password: secret, role: user
> 
> And it's pretty verbose, 65 lines in all.
> 
> What I then decided to do was to write a very simple utility class called
> XmlData that could be used to get this information as easily as possible,
> and that would have basic built-in error reporting. When using the XmlData
> class it is possible to write equivalent code to the above in a fraction of
> the number of lines:
> 
> 	XmlData config = new XmlData("config.xml","config");
> 
> 	out.println("title: "+config.child("title").content());
> 	
> 	XmlData version = config.child("version");
> 	out.println("version:
> "+version.integer("major")+"."+version.integer("minor"));
> 	
> 	for(XmlData role:config.child("roles").children("role")) out.println("role:
> name: "+role.string("name"));
> 	
> 	for(XmlData user:config.child("users").children("user"))
> 	{
> 		out.println(
> 			"user: name: "+user.string("name")+
> 			", password: "+user.string("password")+
> 			", role: "+user.string("role"));
> 	}
> 
> Output:
> 
> 	title: test
> 	version: 1.2
> 	role: name: admin
> 	role: name: user
> 	user: name: joe, password: pass, role: admin
> 	user: name: harry, password: secret, role: user
> 
> As you can see, this is a really simple way to read basic XML files. All
> nodes, attributes and content can very easily be accessed, and only one
> class is required.
> 
> The XmlData class uses DOM to read an XML file then builds its own
> representation of the tree in a very simple form, with only the basic data
> present and all data exposed using standard Collections classes where
> appropriate. The XmlData class source is included at the end of this post.
> 
> So in summary, the main point of this single utility class, XmlData, is to
> provide a very simple and user-friendly way of reading simple XML files that
> may contain simple data such as startup configurations. This class is not
> supposed to be a substitute for DOM and is not intended for high-performance
> scenarios, rather to make XML as easily accessible as possible.
> 
> [One improvement to this may be to base XmlData on SAX rather than DOM in
> order to increase performance]
> 
> My proposal is perhaps to see something like XmlData as a Commons utility
> class.
> 
> All comments very welcome.
> 
> Thanks,
> 
> Chris.
> 
> --
> 
> package main;
> 
> import java.io.FileInputStream;
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.HashMap;
> import java.util.List;
> import java.util.Map;
> 
> import javax.xml.parsers.DocumentBuilder;
> import javax.xml.parsers.DocumentBuilderFactory;
> 
> import org.w3c.dom.Document;
> import org.w3c.dom.Element;
> import org.w3c.dom.NamedNodeMap;
> import org.w3c.dom.Node;
> import org.w3c.dom.NodeList;
> 
> public class XmlData
> {
> 	private static Element rootElement(String filename, String rootName) throws
> Exception
> 	{
> 		FileInputStream fileInputStream = null;
> 		try
> 		{
> 			fileInputStream = new FileInputStream(filename);		
> 			DocumentBuilderFactory builderFactory =
> DocumentBuilderFactory.newInstance();
> 			DocumentBuilder builder = builderFactory.newDocumentBuilder();
> 		    Document document = builder.parse(fileInputStream);
> 		    Element rootElement = document.getDocumentElement();
> 		    if(!rootElement.getNodeName().equals(rootName)) 
> 		    	throw new RuntimeException("Could not find root node: "+rootName);
> 		    return rootElement;
> 		}
> 		finally
> 		{
> 			if(fileInputStream!=null) fileInputStream.close();
> 		}
> 	}
> 	
> 	public XmlData(String filename, String rootName) throws Exception
> 	{
> 		this(rootElement(filename,rootName));
> 	}
> 	
> 	private XmlData(Element element)
> 	{
> 		this.name = element.getNodeName();
> 		this.content = element.getTextContent();
> 		NamedNodeMap namedNodeMap = element.getAttributes();
> 		int n = namedNodeMap.getLength();
> 		for(int i=0;i<n;i++)
> 		{
> 			Node node = namedNodeMap.item(i);
> 			String name = node.getNodeName();
>    		addAttribute(name,node.getNodeValue());
> 		}		
> 		NodeList nodes = element.getChildNodes();
> 		n = nodes.getLength();
> 	    for(int i=0;i<n;i++)
> 	    {
> 	    	Node node = nodes.item(i);
> 	    	int type = node.getNodeType();
> 	    	if(type==Node.ELEMENT_NODE) addChild(node.getNodeName(),new
> XmlData((Element)node));
> 	    }
> 	}
> 	
> 	private void addAttribute(String name, String value)
> 	{
> 		nameAttributes.put(name,value);
> 	}
> 	
> 	private void addChild(String name, XmlData child)
> 	{
> 		List<XmlData> children = nameChildren.get(name);
> 		if(children==null)
> 		{
> 			children = new ArrayList<XmlData>();
> 			nameChildren.put(name,children);
> 		}
> 		children.add(child);
> 	}
> 	
> 	public String name()
> 	{
> 		return name;
> 	}
> 	
> 	public String content()
> 	{
> 		return content;
> 	}
> 	
> 	public XmlData child(String name) throws Exception
> 	{
> 		List<XmlData> children = children(name);
> 		if(children.size()!=1) throw new Exception("Could not find individual
> child node: "+name);
> 		return children.get(0);
> 	}
> 	
> 	public List<XmlData> children(String name)
> 	{
> 		List<XmlData> children = nameChildren.get(name);
> 		return children==null ? Collections.EMPTY_LIST : children;			
> 	}
> 	
> 	public String string(String name) throws Exception
> 	{
> 		String value = nameAttributes.get(name);
> 		if(value==null) throw new Exception("Could not find attribute: "+name+",
> in node: "+this.name);
> 		return value;
> 	}
> 	
> 	public int integer(String name) throws Exception
> 	{
> 		return Integer.parseInt(string(name)); 
> 	}
> 	
> 	private String name;
> 	private String content;
> 	private Map<String,String> nameAttributes = new HashMap<String,String>();
> 	private Map<String,List<XmlData>> nameChildren = new
> HashMap<String,List<XmlData>>();
> }
> -- 
> View this message in context: 
>http://www.nabble.com/Proposal---A-Very-Simple-API-for-Reading-Simple-XML-Data-tp23804602p23804602.html
> Sent from the Apache XML - Commons - Dev mailing list archive at Nabble.com.
> 
> 

Hello,

I'm making this proposal because I couldn't find a good solution to a
problem that I recently had.

What I wanted to do was to configure an application with a simple XML file,
something along the lines of:

<config>
	<title>test</title>
	<version
		major="1"
		minor="2"/>
	<roles>
		<role name="admin"/>
		<role name="user"/>
	</roles>
	<users>
		<user name="joe" password="pass" role="admin"/>
		<user name="harry" password="secret" role="user"/>
	</users>
</config>

So the point is that it's really a very simple bit of XML data and what I
wanted was a nice easy way to read it in. The current options seem to be
SAX, DOM or JAXB.

To use JAXB I need an XSD which is just complicating things too much for a
simple config file. SAX is a bit low-level and complicated too. The best
option is probably DOM, but even DOM is quite verbose. Infact DOM is verbose
enough that it made me think for a while if I could just use some other
mechanism such as a properties file so that I didn't have to bother with
DOM.

For the purpose of this proposal I've written what I think is pretty much
the most concise way to parse this data with DOM. Also note that I want to
provide some basic error reporting if the XML data is not in the expected
format. The code follows below:

	FileInputStream fileInputStream = null;
	try
	{
		String rootName = "config";
		fileInputStream = new FileInputStream("config.xml");		
		DocumentBuilderFactory builderFactory =
DocumentBuilderFactory.newInstance();
		DocumentBuilder builder = builderFactory.newDocumentBuilder();
		Document document = builder.parse(fileInputStream);
		Element rootElement = document.getDocumentElement();
		if(!rootElement.getNodeName().equals(rootName)) 
			throw new Exception("Could not find root node: "+rootName);

		NodeList titles = rootElement.getElementsByTagName("title");
		if(titles.getLength()!=1) throw new Exception("Could not find individual
node: title");
		Node title = titles.item(0);
		out.println("title: "+title.getTextContent());
		
		NodeList versions = rootElement.getElementsByTagName("version");
		if(versions.getLength()!=1) throw new Exception("Could not find individual
node: version");
		Node version = versions.item(0);
		NamedNodeMap versionAttributes = version.getAttributes();
		Node major = versionAttributes.getNamedItem("major");
		if(major==null) throw new Exception("Could not find attribute: major");
		Node minor = versionAttributes.getNamedItem("minor");
		if(minor==null) throw new Exception("Could not find attribute: minor");
		out.println(
			"version:
"+Integer.parseInt(major.getNodeValue())+"."+Integer.parseInt(minor.getNodeValue()));
		
		NodeList roles = rootElement.getElementsByTagName("roles");
		if(roles.getLength()!=1) throw new Exception("Could not find individual
node: roles");
		
		NodeList roleList = ((Element)roles.item(0)).getElementsByTagName("role");
		int n = roleList.getLength();
		for(int i=0;i<n;i++)
		{
			Node role = roleList.item(i);
			Node roleName = role.getAttributes().getNamedItem("name");
			if(roleName==null) throw new Exception("Could not find attribute: name");
			out.println("role: name: "+roleName.getNodeValue());
		}
		
		NodeList users = rootElement.getElementsByTagName("users");
		if(users.getLength()!=1) throw new Exception("Could not find individual
node: users");
		
		NodeList userList = ((Element)users.item(0)).getElementsByTagName("user");
		n = userList.getLength();
		for(int i=0;i<n;i++)
		{
			Node user = userList.item(i);
			NamedNodeMap userAttributes = user.getAttributes();
			Node userName = userAttributes.getNamedItem("name");
			if(userName==null) throw new Exception("Could not find attribute: name");
			Node userPassword = userAttributes.getNamedItem("password");
			if(userPassword==null) throw new Exception("Could not find attribute:
password");
			Node userRole = userAttributes.getNamedItem("role");
			if(userPassword==null) throw new Exception("Could not find attribute:
role");
			out.println(
				"user: name: "+userName.getNodeValue()+
				", password: "+userPassword.getNodeValue()+
				", role: "+userRole.getNodeValue());
		}
	}
	finally
	{
		if(fileInputStream!=null) fileInputStream.close();
	}
	
Output:

	title: test
	version: 1.2
	role: name: admin
	role: name: user
	user: name: joe, password: pass, role: admin
	user: name: harry, password: secret, role: user

And it's pretty verbose, 65 lines in all.

What I then decided to do was to write a very simple utility class called
XmlData that could be used to get this information as easily as possible,
and that would have basic built-in error reporting. When using the XmlData
class it is possible to write equivalent code to the above in a fraction of
the number of lines:

	XmlData config = new XmlData("config.xml","config");

	out.println("title: "+config.child("title").content());
	
	XmlData version = config.child("version");
	out.println("version:
"+version.integer("major")+"."+version.integer("minor"));
	
	for(XmlData role:config.child("roles").children("role")) out.println("role:
name: "+role.string("name"));
	
	for(XmlData user:config.child("users").children("user"))
	{
		out.println(
			"user: name: "+user.string("name")+
			", password: "+user.string("password")+
			", role: "+user.string("role"));
	}

Output:

	title: test
	version: 1.2
	role: name: admin
	role: name: user
	user: name: joe, password: pass, role: admin
	user: name: harry, password: secret, role: user

As you can see, this is a really simple way to read basic XML files. All
nodes, attributes and content can very easily be accessed, and only one
class is required.

The XmlData class uses DOM to read an XML file then builds its own
representation of the tree in a very simple form, with only the basic data
present and all data exposed using standard Collections classes where
appropriate. The XmlData class source is included at the end of this post.

So in summary, the main point of this single utility class, XmlData, is to
provide a very simple and user-friendly way of reading simple XML files that
may contain simple data such as startup configurations. This class is not
supposed to be a substitute for DOM and is not intended for high-performance
scenarios, rather to make XML as easily accessible as possible.

[One improvement to this may be to base XmlData on SAX rather than DOM in
order to increase performance]

My proposal is perhaps to see something like XmlData as a Commons utility
class.

All comments very welcome.

Thanks,

Chris.

--

package main;

import java.io.FileInputStream;
import java.util.ArrayList;
import java.util.Collections;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;

import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.NamedNodeMap;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;

public class XmlData
{
	private static Element rootElement(String filename, String rootName) throws
Exception
	{
		FileInputStream fileInputStream = null;
		try
		{
			fileInputStream = new FileInputStream(filename);		
			DocumentBuilderFactory builderFactory =
DocumentBuilderFactory.newInstance();
			DocumentBuilder builder = builderFactory.newDocumentBuilder();
		    Document document = builder.parse(fileInputStream);
		    Element rootElement = document.getDocumentElement();
		    if(!rootElement.getNodeName().equals(rootName)) 
		    	throw new RuntimeException("Could not find root node: "+rootName);
		    return rootElement;
		}
		finally
		{
			if(fileInputStream!=null) fileInputStream.close();
		}
	}
	
	public XmlData(String filename, String rootName) throws Exception
	{
		this(rootElement(filename,rootName));
	}
	
	private XmlData(Element element)
	{
		this.name = element.getNodeName();
		this.content = element.getTextContent();
		NamedNodeMap namedNodeMap = element.getAttributes();
		int n = namedNodeMap.getLength();
		for(int i=0;i<n;i++)
		{
			Node node = namedNodeMap.item(i);
			String name = node.getNodeName();
    		addAttribute(name,node.getNodeValue());
		}		
		NodeList nodes = element.getChildNodes();
		n = nodes.getLength();
	    for(int i=0;i<n;i++)
	    {
	    	Node node = nodes.item(i);
	    	int type = node.getNodeType();
	    	if(type==Node.ELEMENT_NODE) addChild(node.getNodeName(),new
XmlData((Element)node));
	    }
	}
	
	private void addAttribute(String name, String value)
	{
		nameAttributes.put(name,value);
	}
	
	private void addChild(String name, XmlData child)
	{
		List<XmlData> children = nameChildren.get(name);
		if(children==null)
		{
			children = new ArrayList<XmlData>();
			nameChildren.put(name,children);
		}
		children.add(child);
	}
	
	public String name()
	{
		return name;
	}
	
	public String content()
	{
		return content;
	}
	
	public XmlData child(String name) throws Exception
	{
		List<XmlData> children = children(name);
		if(children.size()!=1) throw new Exception("Could not find individual
child node: "+name);
		return children.get(0);
	}
	
	public List<XmlData> children(String name)
	{
		List<XmlData> children = nameChildren.get(name);
		return children==null ? Collections.EMPTY_LIST : children;			
	}
	
	public String string(String name) throws Exception
	{
		String value = nameAttributes.get(name);
		if(value==null) throw new Exception("Could not find attribute: "+name+",
in node: "+this.name);
		return value;
	}
	
	public int integer(String name) throws Exception
	{
		return Integer.parseInt(string(name)); 
	}
	
	private String name;
	private String content;
	private Map<String,String> nameAttributes = new HashMap<String,String>();
	private Map<String,List<XmlData>> nameChildren = new
HashMap<String,List<XmlData>>();
}
-- 
View this message in context: http://www.nabble.com/Proposal---A-Very-Simple-API-for-Reading-Simple-XML-Data-tp23804602p23804602.html
Sent from the Apache XML - Commons - Dev mailing list archive at Nabble.com.

Thanks Michael, post to follow...


Michael Glavassevich-3 wrote:
> 
> Hello Chris,
> 
> If you have ideas for a new XML Commons component feel free to share them
> with the list.
> 
> Thanks.
> 
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com.
> E-mail: mrglavas@apache.org
> 
> chris0 <technical0@gmail.com> wrote on 05/31/2009 06:18:15 AM:
> 
>> Hello,
>>
>> Suppose I wanted to make a proposal for something to be included in
> Commons,
>> is there any particular way I should go about it, or should I just post
> it
>> in this forum?
>>
>> Thanks,
>>
>> Chris
>> --
>> View this message in context: http://www.nabble.com/How-to-make-a-
>> proposal-tp23801735p23801735.html
>> Sent from the Apache XML - Commons - Dev mailing list archive at
> Nabble.com.
> 

-- 
View this message in context: http://www.nabble.com/Re%3A-How-to-make-a-proposal-tp23802770p23804070.html
Sent from the Apache XML - Commons - Dev mailing list archive at Nabble.com.

Content-type: text/plain; charset=US-ASCII

Hello Chris,

If you have ideas for a new XML Commons component feel free to share them
with the list.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com.
E-mail: mrglavas@apache.org

chris0 <technical0@gmail.com> wrote on 05/31/2009 06:18:15 AM:

> Hello,
>
> Suppose I wanted to make a proposal for something to be included in
Commons,
> is there any particular way I should go about it, or should I just post
it
> in this forum?
>
> Thanks,
>
> Chris
> --
> View this message in context: http://www.nabble.com/How-to-make-a-
> proposal-tp23801735p23801735.html
> Sent from the Apache XML - Commons - Dev mailing list archive at
Nabble.com.

Hello,

Suppose I wanted to make a proposal for something to be included in Commons,
is there any particular way I should go about it, or should I just post it
in this forum?

Thanks,

Chris
-- 
View this message in context: http://www.nabble.com/How-to-make-a-proposal-tp23801735p23801735.html
Sent from the Apache XML - Commons - Dev mailing list archive at Nabble.com.

Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable



Hey all,

The May board meeting is coming up (next week I believe) and we're due =
to
report. The page for the report is setup on the Wiki here:
http://wiki.apache.org/xerces/May2009. As usual I'll cover Xerces-J and=
 XML
Commons. Could other committers please fill in the status for Xerces-C =
and
Xerces-P.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org=

https://issues.apache.org/bugzilla/show_bug.cgi?id=45207


Kevan Simpson <kevan.simpson@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kevan.simpson@gmail.com




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=45207





--- Comment #1 from Kevan Simpson <kevan.simpson@gmail.com>  2009-05-06 18:49:39 PST
---
Encountered same issue, applied patch in local environment and it worked.

When can/will this patch be applied in a release?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47112

           Summary: thread lock of XMLEntityScanner' load method
           Product: XmlCommons
           Version: 1.x
          Platform: HP
        OS/Version: Linux
            Status: NEW
          Severity: critical
          Priority: P2
         Component: SAX
        AssignedTo: commons-dev@xml.apache.org
        ReportedBy: xmlman@nhncorp.com


Hi, 

I’m using xercesImpl-2.8.1.jar in tomcat 5.5.20.
This xerces caused tomcat hang a few days ago.

The thread locks happened after XMLEntityScanner' load method was excuted.
I know there is no the load method of XMLEntityScanner class in version 2.9.
I want to know thre load method of XMLEntityScanner class is bug.
Many java.io.Exception situations after XMLEntityScanner' load call were
searched in Google.

Please help. 

Thanks.

Sample thread of java thread dump follow:

"TP-Processor325" daemon prio=1 tid=0x69eaed00 nid=0xcf0 runnable
[0x68705000..0x687061b0]
         at java.net.SocketInputStream.socketRead0(Native Method)
         at java.net.SocketInputStream.read(SocketInputStream.java:129)
         at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
         at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
         at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
         - locked <0x8eece9e0> (a java.io.BufferedInputStream)
         at
sun.net.www.http.ChunkedInputStream.fastRead(ChunkedInputStream.java:221)
         at
sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:662)
         - locked <0x8eecea00> (a sun.net.www.http.ChunkedInputStream)
         at java.io.FilterInputStream.read(FilterInputStream.java:111)
         at
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2172)
         at
org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read(Unknown
Source)
         at
sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
         at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
         at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183)
         - locked <0x8eeceab0> (a java.io.InputStreamReader)
         at java.io.InputStreamReader.read(InputStreamReader.java:167)
         at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
         at org.apache.xerces.impl.XMLEntityScanner.peekChar(Unknown Source)
         at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(Unknown
Source)
         at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
         at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
         at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
         at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
         at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
         at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
         at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source)
         at org.apache.commons.digester.Digester.parse(Digester.java:1704)
         at com.naver.local.weather.common.DigesterParser.parse(Unknown Source)
         at
com.naver.local.weather.common.bo.WeatherBaseBOImpl.getWeeklyWeatherBeginToday(Unknown
Source)
         at
com.naver.local.weather.common.bo.WeatherBaseBOImpl.getCityWeather(Unknown
Source)
         at
com.naver.local.weather.common.interceptor.LocalInjectInterceptor.setLeftFrameData(Unknown
Source)
         at
com.naver.local.weather.common.interceptor.LocalInjectInterceptor.intercept(Unknown
Source)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.nhncorp.lucy.web.interceptor.PermissionInterceptor.intercept(PermissionInterceptor.java:71)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.nhncorp.lucy.web.interceptor.UserInterceptor.intercept(UserInterceptor.java:88)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.nhncorp.lucy.web.interceptor.MDCLoggingInterceptor.intercept(MDCLoggingInterceptor.java:36)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.nhncorp.lucy.web.interceptor.PagerInfoInterceptor.intercept(PagerInfoInterceptor.java:67)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.nhncorp.lucy.web.interceptor.MetaCharsetInterceptor.intercept(MetaCharsetInterceptor.java:50)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.naver.local.weather.common.interceptor.ContentFilterInterceptor.intercept(Unknown
Source)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.nhncorp.lucy.web.interceptor.RequestParamsInterceptor.intercept(RequestParamsInterceptor.java:44)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.opensymphony.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:186)
         at
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
         at
com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActionProxy.java:116)
         at
com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction(DispatcherUtils.java:225)
         at
com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:202)
         at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
         at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at
com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
         at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
         at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at
com.nhncorp.lucy.web.filter.WebworkActionCheckFilter.doFilter(WebworkActionCheckFilter.java:75)
         at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
         at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at
com.nhncorp.lucy.web.filter.ServiceFilter.doFilter(ServiceFilter.java:85)
         at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
         at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
         at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
         at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
         at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
         at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
         at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
         at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
         at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
         at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
         at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
         at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
         at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
         at java.lang.Thread.run(Thread.java:595)

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Content-type: text/plain; charset=US-ASCII

FYI.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

"Gavin" <gavin@16degrees.com.au> wrote on 04/11/2009 05:15:02 AM:

> Hi All,
>
> This is a heads-up that Buildbot CI server is now available for projects
> use.
>
> Some projects that have been used for testing Buildbot here at the ASF
can
> be seen at http://ci.apache.org.
>     I have a development installation at
> http://build01.16degrees.com.au:8020/waterfall where I have been testing
> many more projects (about 20 including the Buildbot project itself).
>
> Any new or existing project that wants to add Buildbot to their arsenal
of
> tools to help them build,test,snapshot,deploy,etc can create an issue on
the
> Infrastructure Issue Tracker :
>
> https://issues.apache.org/jira/browse/INFRA/component/12312782
>
> There has been a new mailing list created specifically for all our CI
> servers (Buildbot, Hudson, Continuum) - builds@apache.org - sign up at
> builds-subscribe@apache.org .
>
> I made use of our infra blog and posted a short note about it at
>
> https://blogs.apache.org/infra/entry/new_mailing_list_for_ci
>
> So, any requests to make use of any of the build servers are made to the
> appropriate Jira component on the Infra Issue Tracker. All discussions
> regarding them should be directed to the builds@apache.org list from now
on.
>
> Thanks, and see you there!
>
> Gav...

Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable



Hi all,

Applications for this summer's GSoC will be starting on Monday. As many=
 of
you know Xerces has participated the last three years. Looking forward =
to
the opportunity again.

I'm planning on posting a couple project ideas or so for Xerces-J. If
you're also interested in being a mentor feel free to add your own idea=
s to
the Wiki, and if you're a student interested in participating we'd like=
 to
hear from you with your ideas.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Luciano Resende <lresende@apache.org> wrote on 03/19/2009 05:52:29 PM:

> Dear PMC,
>
> It's now official, Google has announced that The Apache Software
> Foundation was selected as one of the participating organization in
> the GSoC 2009 program. This is an excellent opportunity for Apache, a=
s
> it allows projects to build/increase its community, it also help
> students to learn about open source, about Apache Software Foundation=

> and how to do things the "Apache Way".
>
> Please start advertising the program and discussing project ideas wit=
h
> your project community. Then add your project ideas to the ASF GSoC
> 2009 Official Project Ideas page [1], as this is going to be the most=

> visible place for students. Per GSoC 2009 timeline, Students should
> officially start applying for these ideas on March 23.
>
> ASF Members and committers can volunteer to be mentors in the GSoC
> 2009 program (see [2] for more details about being a mentor). We
> invite all mentors and GSoC interested parties to subscribe to the
> code-awards@a.o mailing list [3] to coordinate work between mentors,
> ask questions and get updates related to GSoC 2009 program.
>
> Please, feel free to forward this announce to any appropriate dev@ or=

> users@ lists so your larger community can hear about the GSoC 2009
> program.
>
> [1] http://wiki.apache.org/general/SummerOfCode2009
> [2] http://wiki.apache.org/general/SummerOfCodeMentor
> [3] mailto:code-awards-subscribe@apache.org
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/=

Content-type: text/plain; charset=US-ASCII

Richard <wrongch@gmail.com> wrote on 03/13/2009 12:20:42 AM:

> Hi, I got such problem with importNode, when try to import a Node
> from one Document into another.
>
> DocumentA
> <?xml version='1.0' encoding='utf-8'?><m:root xmlns:m='TEST'><m:
> s>TEST</m:s></m:root>
> DocumentB:
> <?xml version='1.0' encoding='utf-8' ?><n:root xmlns:n='TEST'><n:
> t>TEST</n:t></n:root>
>
> I try to import m:s in DocumentA into DocumentB, and replace n:t Node
>
> expected:
> <?xml version='1.0' encoding='utf-8' ?><n:root xmlns:n='TEST'><n:
> s>TEST</n:s></n:root>
>
> but the result was:
> <?xml version='1.0' encoding='utf-8' ?><n:root xmlns:n='TEST'><m:
> s>TEST</m:s></n:root>
>
> Can somebody tell me why?

You've left out all sorts of details, but you're probably not using a
namespace-aware or namespace fixing serializer when you serialize the
document. DOM Level 3's LSSerializer would write [1] this out correctly.

Thanks.

[1]
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/namespaces-algorithms.html#normalizeDocumentAlgo

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Hi, I got such problem with importNode, when try to import a Node from one
Document into another.


DocumentA
<?xml version='1.0' encoding='utf-8'?><m:root
xmlns:m='TEST'><m:s>TEST</m:s></m:root>
DocumentB:
<?xml version='1.0' encoding='utf-8' ?><n:root
xmlns:n='TEST'><n:t>TEST</n:t></n:root>

I try to import m:s in DocumentA into DocumentB, and replace n:t Node

expected:
<?xml version='1.0' encoding='utf-8' ?><n:root
xmlns:n='TEST'><n:s>TEST</n:s></n:root>

but the result was:
<?xml version='1.0' encoding='utf-8' ?><n:root
xmlns:n='TEST'><m:s>TEST</m:s></n:root>


Can somebody tell me why?