forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: view/viewHelper XHTML code generation
Date Mon, 02 May 2005 11:45:05 GMT
Diwaker Gupta wrote:
> Hi everyone,
> There are a number of small but important problems with the
> view/viewHelper XHTML code generation. Actually, my guess is that this
> is not really a problem of the plugin, since I believe the contract
> definition delegates the actual XHTML generation to Cocoon?
> Anyways, basically I took one of the generated pages and ran it
> through W3's validator. Here are some of the major problems, and each
> one of them should be easily fixable. I'm happy to prepare a patch,
> only that I'm not very familiar with the code that does XHTML
> generation. So if someone can point me to it, I'll be glad to help.
> o generated XHTML starts with an <?xml tag. I'm not sure thats the
> expected behavior. IIRC documents should start with the DOCTYPE tag.
> In the current setup, the validator returns a "DTD did not contain
> element declaration for document type name" error

XHTML is XML and therefore must start with the XML processig instruction.

> o Then the root element of the XHTML seems to be a <xhtml> tag. There
> is NO such tag. Documents *must* have <html> as the root element.

That is an error.

> There are no attributes such as xmlns:forrest and xmlns:xi either. Why
> do we need them in the generated XHTML anyways?

These are left in as a result of previous transformations. The xmlns:xi
is from the xinclude transformer.

> o Many of the "<a name='xxx'>" type tags generated (eg: for section
> headings) contain invalid characters. At some places spaces have been
> converted to "%".

Are you sure it's not %20, which is correct.

> At other places, a long title has been shorted to 2
> words joined together by a "+" sign to generate the value of the
> 'name' attribute -- again, XHTML strict does not allow '+' sign in
> this context.

Really, well if it's not allowed then we need to escape it or use
another symbol.

> Why go through all this trouble for character
> substitution? Just use spaces :)

Because id attriburtes cannot have spaces in them.

> o The feedback contract generates a div tag with an attribute
> xmlns:jx, which is again invalid. Why is this needed?

This appears to be coming from the files in view:

$ find . -name "*.xml" -exec grep -H xmlns:jx {} \;

> Finally, validation will go a lot smoother if we just use XHTML
> transitional instead of XHTML strict for now. Once we validate
> transitional, we can push for strict. Though I'm all for aiming for
> strict from the beginning!

We say we are an XML standards project, I'd prefer to go for strict from
the outset. There is a tendency to be happy with passed tests regardless
of which are being passed.

Having said that, I'm not the one doing this work, so I won't stand in
your way :-))


View raw message