David Crossley wrote:
Steven Noels wrote:

David Crossley wrote:


The <map:transformer> used to have children like
<use-session-info> etc. but these have been recently
changed to <use-session-parameters> etc. However,
the sitemap.rng still has the former. Also, the code in
o.a.c.transformation.TraxTransformer still uses the
former. Are these just typos in the new sitemap.xmap?

This brings http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103847911212458&w=2 back to mind. What 'level' of validation are we able to obtain if we try to put everything into one grammar, which must fit each and every component...? Hm. Bruno is on skying holiday ATM, I'll refer him to this when he's back.


I look forward to Bruno's expertise and help on this
and other matters.

Yes, i agree with the need for a more clever, component-based
approach as soon as possible.

In the meantime, we need something to help keep the new build
on the rails. Already errors have crept in.

I just added the few basic validations that we had in the
old build:
* cocoon.roles - quite strict structural validation.
* cocoon.xconf - extremely loose validation, could be improved.
* sitemap.xmap - cumbersome, but works for now.

The one thing that is missing at the moment is the ability
to have validate.config=false to get around any immediate
build issues. I will try to add that today. (However i am away
for one week holiday, then catch-up.)

So the sitemap validation and the roles validation are
commented-out in the current build. Pity, because that does
not put the build issues in everyone's face.

                         -- o --
The other purpose of my original message was to raise an alarm
about the change in parameter names in the sitemap, which now
do not correspond with code o.a.c.transformation.TraxTransformer

I'm more and more considering sitemap validation harmful.


why:

1) the sitemap logic is too hard to be validated from any validation language (it requires java runtime capabilitles)

2) it reduces the effort of clean and meaningful error messages in the treeprocessor

Example, try

<generate uri="..."/>

where the uri attribute is not allowed in generate (shoulc be 'src'), the treeprocessor totally ignores this and sends the empty string to the parser, resulting in the error

System ID not found!

Sitemap validation has stopped us from fixing the error messaging capabilities on mistakes.

I propose to blast the sitemap validation alltogether.



Reply via email to