Hmm..
The original files (eg impl/src/main/tld/myfaces_core.tld) don't have
any xmlns declaration in them. It does have this:
<!DOCTYPE taglib
PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"
"http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd"; [
It also has xml entity references that need expanding.
However after processing to expand the xml entities, the resulting
"expanded" files do have an xmlns declarations on the base <taglib>
element, because the referenced DTD has this:
<!ELEMENT taglib (tlib-version, jsp-version, short-name, uri?,
display-name?, small-icon?, large-icon?, description?,
validator?, listener*, tag+) >
<!ATTLIST taglib id ID #IMPLIED
xmlns CDATA #FIXED
"http://java.sun.com/JSP/TagLibraryDescriptor";>
This all seems valid to me, though I've not seen a DTD declare an xmlns for an
element before.
Still, whether it's explicitly provided inline or implicitly inserted by the
DTD, the effect is the same.
When the tlddoc application v1.3 is run on this expanded file, the following
results:
com.sun.tlddoc.GeneratorException: Error: myfaces_core.tld does not have
xmlns="http://java.sun.com/xml/ns/javaee";
I've confirmed that manually changing the xmlns declaration in the input tld
file to the one above does allow the file to be processed.
Deleting it also has the same effect; presumably because the tlddoc application
registers an internal DTD file with public
identifier "
All the above seems to me to imply that v1.3 of tlddoc does not support JSP1.2
tag libraries. So we shouldn't be using that version of tlddoc.
Unforunately I tested v1.2 of tlddoc, and got the same error (wants ns/javaee).
And version 1.1 of tlddoc appears to want a <taglib> tag
with no associated namespace at all.
Regardless, I can't see any problem with what MyFaces is doing; it looks like
either a stuffup in the tlddoc project or
a stuffup in the sun web-jsptaglibrary_1_2.dtd file.
Regards,
Simon
On Fri, 2006-01-13 at 08:17 +0100, Bernd Bohmann wrote:
> The Problem is the
>
> <taglib xmlns="http://java.sun.com/JSP/TagLibraryDescriptor"; >
>
> in the generated tld.
> The tlddoc generator doesn't allow
> http://java.sun.com/JSP/TagLibraryDescriptor for the xmlns attribute.
>
> One solution is
>
> remove the
>
> PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"
> "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd";
>
> in
>
> <!DOCTYPE taglib
> PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"
> "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd"; [
> <!ENTITY validator_min_max_attributes SYSTEM
> "entities/validator_min_max_attributes.xml">
>
> from the source tld's in src/main/tld
>
> or
>
> use a different xsl for generating the tld's, But the changed xsl has no
> indenting support(indent is activated but it doesn't work maybe a
> transformer bug in jdk).
>
> With both solutions the generated tld's contains the doctype-public and
> the doctype-system, but no xmlns attribute.
>
>
> Arvid is member of the tobago team.
>
>
> Regards
>
> Bernd
>
>
>
> Simon Kitching schrieb:
>
> >
> > I'm confused. Could someone please explain what this xls/dtd issues is
> > actually about, and what Arvid's suggestions mean (BTW, who is Arvid?).
> >
> > What is the problem that is actually occurring?
> >
> > I would think that removing public declarations is not allowed; that
> > defines the document type. Without a public declaration, an xml document
> > is meaningless - or at least has no "context" to be interpreted in.
> >
> > I see the alternative was something to do with removing indenting from
> > something? Which files are we talking about, and why would indenting
> > have anything to do with it?
> >
> >
> > Cheers,
> >
> > Simon
> >
> >
>
