You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by David Crossley <cr...@indexgeo.com.au> on 2001/10/25 10:58:52 UTC
XML validation during build docs
Has the "build docs" stopped doing validation of xdocs, or
do i imagine that? I recall that when the build was controlled
by Ant, then it was doing full XML validation. I am sure that
i often received validation errors while developing my xdocs.
Now that the build is run by Cocoon then it only does a
well-formedness check. I tested the current situation by
deliberately breaking index.xml by removing the mandatory
<title> element, then by just removing the closing tag.
I think that i know why. The Ant build used Xerces directly
where validation was probably default true. Whereas, in
Cocoon the parser should, and does, have validation=false.
I see that components/parser/XercesParser.java has
setFeature validation=false. However, the default
JaxpParser.java does not setFeature validation in any way.
I would think it desible to have validation happening for
the documentation build, and of course, not happening
while running as a servlet. Is there a way?
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Action selection in sitemap
Posted by giacomo <gi...@apache.org>.
On Thu, 8 Nov 2001, Davanum Srinivas wrote:
> Konstantin,
>
> +1. But please experiment in C2.1 HEAD, Then send out an email for a vote.
Careful. Would we like to break backwards compatability on this?
Giacomo
>
> Thanks,
> dims
>
> --- "Piroumian, Konstantin" <KP...@flagship.ru> wrote:
> > So, if no comments on this then I'll add this feature to sitemap. But I'd
> > like to know if others also interested in something like this or there is
> > another way for the same thing?
> >
> > Maybe this is more clear:
> >
> > <!-- A new attribute will make it possible to select actions without using
> > hard-coded 'cocoon-action' request parameter, but depending on the URL:
> > /registration/Start
> > ...
> > /registration/Stop
> > here:
> > /registration - the matched action set
> > Start, Stop - the selected action
> > -->
> > <map:match pattern="registration/*">
> > <map:act-set type="registration-process" action-name="{1}">
> > <map:read type="jsp" src="jsp/{current-page}.jsp"
> > </map:act>
> > </map:match>
> >
> > Current implementation can be changed to a more flexible if we add an extra
> > attribute to the action-set, e.g.:
> > <map:act-set type="registration-process"
> > action-param-name="cocoon-action">
> >
> > > Hi, C2ers!
> > >
> > > I've already asked this question and it seems that nobody could answer it.
> > > The question is: why the Environment interface has getAction() method
> > which
> > > returns the value of 'cocoon-action' (hard-coded) parameter from the
> > > request. It would be much better to be able to set the action name (or a
> > > filter/pattern expression) in the sitemap. E.g.:
> > >
> > > <!-- For a registration process we have three actions: start, user input
> > > processing, cancel -->
> > > <map:actions>
> > > <map:action name="start-process" src="regtest.StartProcessAction"/>
> > > <map:action name="input-process" src="regtest.InputAction"/>
> > > <map:action name="cancel-process" src="regtest.CancelProcessAction"/>
> > > </map:actions>
> > >
> > > <!-- The action set for the registration process -->
> > > <map:action-sets>
> > > <map:action-set name="registration-process">
> > > <map:act type="start-process" action="Start"/>
> > > <map:act type="input-process" action="Input"/>
> > > <map:act type="cancel-process" action="Cancel"/>
> > > </map:action-set>
> > > </map:action-sets>
> > >
> > > <!-- Entry point for all registration requests -->
> > > <map:match pattern="registration/*">
> > > <map:act-set type="registration-process" action="{1}">
> > > <map:read type="jsp" src="jsp/{current-page}.jsp"
> > > </map:act>
> > > <map:read src="html/error.htm"/>
> > > </map:match>
> > >
> > > So, requests will be of this form:
> > > /registration/Start - the StartProcessAction will be called
> > > /registration/Input - InputAction
> > > /registration/Cancel - CancelProcessAction
> > >
> > > As you can see there is no need to use any '?cocoon-action=Start' or so in
> > > the request and IMO using 'registration/Start' is much better - you have
> > > clean separation of posted data and the action. I think, it will be easy
> > to
> > > implement, but requires changes to Environment interface (remove or
> > > deprecate getAction()).
> > >
> > > The document that pushed me to this idea is related to Struts, but it can
> > > apply also to C2 application development as well:
> > > http://husted.com/about/scaffolding/catalog.htm . Many good
> > > advice/hints/tricks from it could be used in C2 too.
> > >
> > > Are there any comments on this or other ideas?
> > >
> > > Btw, comparing Struts and Cocoon, I must admit, that Struts has much more
> > > clear concepts and it's much easier in use and installation than Cocoon.
> > The
> > > only thing that keeps me with C2 is that Struts has no XML/XSP/XSLT
> > > capabilities and almost all its features are only a subset of Cocoon's and
> > > can be easily implemented with C2.
> > >
> > > Best regards,
> > >
> > > Konstantin Piroumian
> > > Program Leader
> > >
> > > Protek Flagship LLC
> > > Phone: + 7 095 795 0520 (add. 1288)
> > > Fax: + 7 095 795 0525
> > > E-mail: kpiroumian@flagship.ru
> > > http://www.protek.com
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
>
> =====
> Davanum Srinivas - http://jguru.com/dims/
>
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Action selection in sitemap
Posted by Davanum Srinivas <di...@yahoo.com>.
Konstantin,
+1. But please experiment in C2.1 HEAD, Then send out an email for a vote.
Thanks,
dims
--- "Piroumian, Konstantin" <KP...@flagship.ru> wrote:
> So, if no comments on this then I'll add this feature to sitemap. But I'd
> like to know if others also interested in something like this or there is
> another way for the same thing?
>
> Maybe this is more clear:
>
> <!-- A new attribute will make it possible to select actions without using
> hard-coded 'cocoon-action' request parameter, but depending on the URL:
> /registration/Start
> ...
> /registration/Stop
> here:
> /registration - the matched action set
> Start, Stop - the selected action
> -->
> <map:match pattern="registration/*">
> <map:act-set type="registration-process" action-name="{1}">
> <map:read type="jsp" src="jsp/{current-page}.jsp"
> </map:act>
> </map:match>
>
> Current implementation can be changed to a more flexible if we add an extra
> attribute to the action-set, e.g.:
> <map:act-set type="registration-process"
> action-param-name="cocoon-action">
>
> > Hi, C2ers!
> >
> > I've already asked this question and it seems that nobody could answer it.
> > The question is: why the Environment interface has getAction() method
> which
> > returns the value of 'cocoon-action' (hard-coded) parameter from the
> > request. It would be much better to be able to set the action name (or a
> > filter/pattern expression) in the sitemap. E.g.:
> >
> > <!-- For a registration process we have three actions: start, user input
> > processing, cancel -->
> > <map:actions>
> > <map:action name="start-process" src="regtest.StartProcessAction"/>
> > <map:action name="input-process" src="regtest.InputAction"/>
> > <map:action name="cancel-process" src="regtest.CancelProcessAction"/>
> > </map:actions>
> >
> > <!-- The action set for the registration process -->
> > <map:action-sets>
> > <map:action-set name="registration-process">
> > <map:act type="start-process" action="Start"/>
> > <map:act type="input-process" action="Input"/>
> > <map:act type="cancel-process" action="Cancel"/>
> > </map:action-set>
> > </map:action-sets>
> >
> > <!-- Entry point for all registration requests -->
> > <map:match pattern="registration/*">
> > <map:act-set type="registration-process" action="{1}">
> > <map:read type="jsp" src="jsp/{current-page}.jsp"
> > </map:act>
> > <map:read src="html/error.htm"/>
> > </map:match>
> >
> > So, requests will be of this form:
> > /registration/Start - the StartProcessAction will be called
> > /registration/Input - InputAction
> > /registration/Cancel - CancelProcessAction
> >
> > As you can see there is no need to use any '?cocoon-action=Start' or so in
> > the request and IMO using 'registration/Start' is much better - you have
> > clean separation of posted data and the action. I think, it will be easy
> to
> > implement, but requires changes to Environment interface (remove or
> > deprecate getAction()).
> >
> > The document that pushed me to this idea is related to Struts, but it can
> > apply also to C2 application development as well:
> > http://husted.com/about/scaffolding/catalog.htm . Many good
> > advice/hints/tricks from it could be used in C2 too.
> >
> > Are there any comments on this or other ideas?
> >
> > Btw, comparing Struts and Cocoon, I must admit, that Struts has much more
> > clear concepts and it's much easier in use and installation than Cocoon.
> The
> > only thing that keeps me with C2 is that Struts has no XML/XSP/XSLT
> > capabilities and almost all its features are only a subset of Cocoon's and
> > can be easily implemented with C2.
> >
> > Best regards,
> >
> > Konstantin Piroumian
> > Program Leader
> >
> > Protek Flagship LLC
> > Phone: + 7 095 795 0520 (add. 1288)
> > Fax: + 7 095 795 0525
> > E-mail: kpiroumian@flagship.ru
> > http://www.protek.com
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas - http://jguru.com/dims/
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Action selection in sitemap
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> On Thu, 8 Nov 2001, Piroumian, Konstantin wrote:
>
> You know that this breaks backword compatability and I havn't got your
> response onto mail my as I don't see how this fits into form base action
> selection where a button determines the action to take (these are not
> encoded into the URL path but as parameters).
Why do you think that this will break compatibility?
We can leave the old behavior as default and add this new functionality. I
don't think that adding new features will break somebodys' sitemaps if I
keep the old ones as defaults.
See my other response regarding this way of action selection.
Konstantin
>
> Giacomo
>
> > So, if no comments on this then I'll add this feature to sitemap. But
I'd
> > like to know if others also interested in something like this or there
is
> > another way for the same thing?
> >
> > Maybe this is more clear:
> >
> > <!-- A new attribute will make it possible to select actions without
using
> > hard-coded 'cocoon-action' request parameter, but depending on the URL:
> > /registration/Start
> > ...
> > /registration/Stop
> > here:
> > /registration - the matched action set
> > Start, Stop - the selected action
> > -->
> > <map:match pattern="registration/*">
> > <map:act-set type="registration-process" action-name="{1}">
> > <map:read type="jsp" src="jsp/{current-page}.jsp"
> > </map:act>
> > </map:match>
> >
> > Current implementation can be changed to a more flexible if we add an
extra
> > attribute to the action-set, e.g.:
> > <map:act-set type="registration-process"
> > action-param-name="cocoon-action">
> >
> > > Hi, C2ers!
> > >
> > > I've already asked this question and it seems that nobody could answer
it.
> > > The question is: why the Environment interface has getAction() method
> > which
> > > returns the value of 'cocoon-action' (hard-coded) parameter from the
> > > request. It would be much better to be able to set the action name (or
a
> > > filter/pattern expression) in the sitemap. E.g.:
> > >
> > > <!-- For a registration process we have three actions: start, user
input
> > > processing, cancel -->
> > > <map:actions>
> > > <map:action name="start-process"
src="regtest.StartProcessAction"/>
> > > <map:action name="input-process" src="regtest.InputAction"/>
> > > <map:action name="cancel-process"
src="regtest.CancelProcessAction"/>
> > > </map:actions>
> > >
> > > <!-- The action set for the registration process -->
> > > <map:action-sets>
> > > <map:action-set name="registration-process">
> > > <map:act type="start-process" action="Start"/>
> > > <map:act type="input-process" action="Input"/>
> > > <map:act type="cancel-process" action="Cancel"/>
> > > </map:action-set>
> > > </map:action-sets>
> > >
> > > <!-- Entry point for all registration requests -->
> > > <map:match pattern="registration/*">
> > > <map:act-set type="registration-process" action="{1}">
> > > <map:read type="jsp" src="jsp/{current-page}.jsp"
> > > </map:act>
> > > <map:read src="html/error.htm"/>
> > > </map:match>
> > >
> > > So, requests will be of this form:
> > > /registration/Start - the StartProcessAction will be called
> > > /registration/Input - InputAction
> > > /registration/Cancel - CancelProcessAction
> > >
> > > As you can see there is no need to use any '?cocoon-action=Start' or
so in
> > > the request and IMO using 'registration/Start' is much better - you
have
> > > clean separation of posted data and the action. I think, it will be
easy
> > to
> > > implement, but requires changes to Environment interface (remove or
> > > deprecate getAction()).
> > >
> > > The document that pushed me to this idea is related to Struts, but it
can
> > > apply also to C2 application development as well:
> > > http://husted.com/about/scaffolding/catalog.htm . Many good
> > > advice/hints/tricks from it could be used in C2 too.
> > >
> > > Are there any comments on this or other ideas?
> > >
> > > Btw, comparing Struts and Cocoon, I must admit, that Struts has much
more
> > > clear concepts and it's much easier in use and installation than
Cocoon.
> > The
> > > only thing that keeps me with C2 is that Struts has no XML/XSP/XSLT
> > > capabilities and almost all its features are only a subset of Cocoon's
and
> > > can be easily implemented with C2.
> > >
> > > Best regards,
> > >
> > > Konstantin Piroumian
> > > Program Leader
> > >
> > > Protek Flagship LLC
> > > Phone: + 7 095 795 0520 (add. 1288)
> > > Fax: + 7 095 795 0525
> > > E-mail: kpiroumian@flagship.ru
> > > http://www.protek.com
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Action selection in sitemap
Posted by giacomo <gi...@apache.org>.
On Thu, 8 Nov 2001, Piroumian, Konstantin wrote:
You know that this breaks backword compatability and I havn't got your
response onto mail my as I don't see how this fits into form base action
selection where a button determines the action to take (these are not
encoded into the URL path but as parameters).
Giacomo
> So, if no comments on this then I'll add this feature to sitemap. But I'd
> like to know if others also interested in something like this or there is
> another way for the same thing?
>
> Maybe this is more clear:
>
> <!-- A new attribute will make it possible to select actions without using
> hard-coded 'cocoon-action' request parameter, but depending on the URL:
> /registration/Start
> ...
> /registration/Stop
> here:
> /registration - the matched action set
> Start, Stop - the selected action
> -->
> <map:match pattern="registration/*">
> <map:act-set type="registration-process" action-name="{1}">
> <map:read type="jsp" src="jsp/{current-page}.jsp"
> </map:act>
> </map:match>
>
> Current implementation can be changed to a more flexible if we add an extra
> attribute to the action-set, e.g.:
> <map:act-set type="registration-process"
> action-param-name="cocoon-action">
>
> > Hi, C2ers!
> >
> > I've already asked this question and it seems that nobody could answer it.
> > The question is: why the Environment interface has getAction() method
> which
> > returns the value of 'cocoon-action' (hard-coded) parameter from the
> > request. It would be much better to be able to set the action name (or a
> > filter/pattern expression) in the sitemap. E.g.:
> >
> > <!-- For a registration process we have three actions: start, user input
> > processing, cancel -->
> > <map:actions>
> > <map:action name="start-process" src="regtest.StartProcessAction"/>
> > <map:action name="input-process" src="regtest.InputAction"/>
> > <map:action name="cancel-process" src="regtest.CancelProcessAction"/>
> > </map:actions>
> >
> > <!-- The action set for the registration process -->
> > <map:action-sets>
> > <map:action-set name="registration-process">
> > <map:act type="start-process" action="Start"/>
> > <map:act type="input-process" action="Input"/>
> > <map:act type="cancel-process" action="Cancel"/>
> > </map:action-set>
> > </map:action-sets>
> >
> > <!-- Entry point for all registration requests -->
> > <map:match pattern="registration/*">
> > <map:act-set type="registration-process" action="{1}">
> > <map:read type="jsp" src="jsp/{current-page}.jsp"
> > </map:act>
> > <map:read src="html/error.htm"/>
> > </map:match>
> >
> > So, requests will be of this form:
> > /registration/Start - the StartProcessAction will be called
> > /registration/Input - InputAction
> > /registration/Cancel - CancelProcessAction
> >
> > As you can see there is no need to use any '?cocoon-action=Start' or so in
> > the request and IMO using 'registration/Start' is much better - you have
> > clean separation of posted data and the action. I think, it will be easy
> to
> > implement, but requires changes to Environment interface (remove or
> > deprecate getAction()).
> >
> > The document that pushed me to this idea is related to Struts, but it can
> > apply also to C2 application development as well:
> > http://husted.com/about/scaffolding/catalog.htm . Many good
> > advice/hints/tricks from it could be used in C2 too.
> >
> > Are there any comments on this or other ideas?
> >
> > Btw, comparing Struts and Cocoon, I must admit, that Struts has much more
> > clear concepts and it's much easier in use and installation than Cocoon.
> The
> > only thing that keeps me with C2 is that Struts has no XML/XSP/XSLT
> > capabilities and almost all its features are only a subset of Cocoon's and
> > can be easily implemented with C2.
> >
> > Best regards,
> >
> > Konstantin Piroumian
> > Program Leader
> >
> > Protek Flagship LLC
> > Phone: + 7 095 795 0520 (add. 1288)
> > Fax: + 7 095 795 0525
> > E-mail: kpiroumian@flagship.ru
> > http://www.protek.com
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Action selection in sitemap
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
So, if no comments on this then I'll add this feature to sitemap. But I'd
like to know if others also interested in something like this or there is
another way for the same thing?
Maybe this is more clear:
<!-- A new attribute will make it possible to select actions without using
hard-coded 'cocoon-action' request parameter, but depending on the URL:
/registration/Start
...
/registration/Stop
here:
/registration - the matched action set
Start, Stop - the selected action
-->
<map:match pattern="registration/*">
<map:act-set type="registration-process" action-name="{1}">
<map:read type="jsp" src="jsp/{current-page}.jsp"
</map:act>
</map:match>
Current implementation can be changed to a more flexible if we add an extra
attribute to the action-set, e.g.:
<map:act-set type="registration-process"
action-param-name="cocoon-action">
> Hi, C2ers!
>
> I've already asked this question and it seems that nobody could answer it.
> The question is: why the Environment interface has getAction() method
which
> returns the value of 'cocoon-action' (hard-coded) parameter from the
> request. It would be much better to be able to set the action name (or a
> filter/pattern expression) in the sitemap. E.g.:
>
> <!-- For a registration process we have three actions: start, user input
> processing, cancel -->
> <map:actions>
> <map:action name="start-process" src="regtest.StartProcessAction"/>
> <map:action name="input-process" src="regtest.InputAction"/>
> <map:action name="cancel-process" src="regtest.CancelProcessAction"/>
> </map:actions>
>
> <!-- The action set for the registration process -->
> <map:action-sets>
> <map:action-set name="registration-process">
> <map:act type="start-process" action="Start"/>
> <map:act type="input-process" action="Input"/>
> <map:act type="cancel-process" action="Cancel"/>
> </map:action-set>
> </map:action-sets>
>
> <!-- Entry point for all registration requests -->
> <map:match pattern="registration/*">
> <map:act-set type="registration-process" action="{1}">
> <map:read type="jsp" src="jsp/{current-page}.jsp"
> </map:act>
> <map:read src="html/error.htm"/>
> </map:match>
>
> So, requests will be of this form:
> /registration/Start - the StartProcessAction will be called
> /registration/Input - InputAction
> /registration/Cancel - CancelProcessAction
>
> As you can see there is no need to use any '?cocoon-action=Start' or so in
> the request and IMO using 'registration/Start' is much better - you have
> clean separation of posted data and the action. I think, it will be easy
to
> implement, but requires changes to Environment interface (remove or
> deprecate getAction()).
>
> The document that pushed me to this idea is related to Struts, but it can
> apply also to C2 application development as well:
> http://husted.com/about/scaffolding/catalog.htm . Many good
> advice/hints/tricks from it could be used in C2 too.
>
> Are there any comments on this or other ideas?
>
> Btw, comparing Struts and Cocoon, I must admit, that Struts has much more
> clear concepts and it's much easier in use and installation than Cocoon.
The
> only thing that keeps me with C2 is that Struts has no XML/XSP/XSLT
> capabilities and almost all its features are only a subset of Cocoon's and
> can be easily implemented with C2.
>
> Best regards,
>
> Konstantin Piroumian
> Program Leader
>
> Protek Flagship LLC
> Phone: + 7 095 795 0520 (add. 1288)
> Fax: + 7 095 795 0525
> E-mail: kpiroumian@flagship.ru
> http://www.protek.com
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Action selection in sitemap
Posted by giacomo <gi...@apache.org>.
On Fri, 9 Nov 2001, Piroumian, Konstantin wrote:
>
> > > Hi, C2ers!
> > >
> > > I've already asked this question and it seems that nobody could answer
> it.
> > > The question is: why the Environment interface has getAction() method
> which
> > > returns the value of 'cocoon-action' (hard-coded) parameter from the
> > > request. It would be much better to be able to set the action name (or a
> > > filter/pattern expression) in the sitemap. E.g.:
> > >
> > >
> <skipped>
> > > So, requests will be of this form:
> > > /registration/Start - the StartProcessAction will be called
> > > /registration/Input - InputAction
> > > /registration/Cancel - CancelProcessAction
> >
> > Of course this is a way to go. Can you give an example if the actual
> > action request is comming from a html button in a form (is encoded as a
> > parameter instead of URI-path)?
>
> The action request comes from different HTML forms but processed by the same
> matcher "registration/*". Which button caused this submit in this case is
> processed internally by the appropriate action.
>
> After thinking a little more I came to this three ways of determining the
> action:
> 1 an URL part (all buttons are processed by the action)
> 2 action parameter (like 'cocoon-action' - one param name - multiple
> actions)
> 3 different parameters (e.g., three buttons with different names on a
> form. It doesn't matter what the value is - we need to check if the
> parameter is present)
>
> The first case is useful when you have a single action for all buttons on a
> form (e.g. the actual processing is performed on the back-end and you don't
> care which button had been clicked, e.g. in an EJB or Workflow application).
>
> The second case is currently used in C2, but the main disadvantage of it is
> that you depend on the button value, which is an issue in a multilanguage
> application (alternatively, a hidden field with JavaScript can be used -
> this is not a good solution either)
>
> The third case IMO is best: you have as many buttons as you like, and any
> labels (values) - you only get one button on submit and you check which one
> of the possible params is present.
>
> So, I can suggest to improve C2 action selection mechanism to support all 3
> cases. It seems to me that it will require some changes in interfaces and
> not so easy to implement (from the first look).
>
> Btw, 'cocoon-view' parameter name is also hard-coded. Maybe it'll be better
> to invent some kind of a selection mechanism (instead of using sitemap
> selectors) based on attributes for things that depend on request parameter
> names, values and presence?
Carefull with this. The view concept is very fragile at the moment. It
could/will change in the future when there are semantic web crawlers
around which really need to use views. I'll say don't touch it ATM. One
way to go here would be to respect extentions as view names (ie:
resource.html, resource.xml, resource.xsd resource.rdf and of course
resource itself as the default view)
Giacomo
>
> Regards,
> Konstantin Piroumian
>
> >
> > And, yes, patches are welcome.
> >
> > Giacomo
> >
> > >
> > > As you can see there is no need to use any '?cocoon-action=Start' or so
> in
> > > the request and IMO using 'registration/Start' is much better - you have
> > > clean separation of posted data and the action. I think, it will be easy
> to
> > > implement, but requires changes to Environment interface (remove or
> > > deprecate getAction()).
> > >
> > > The document that pushed me to this idea is related to Struts, but it
> can
> > > apply also to C2 application development as well:
> > > http://husted.com/about/scaffolding/catalog.htm . Many good
> > > advice/hints/tricks from it could be used in C2 too.
> > >
> > > Are there any comments on this or other ideas?
> > >
> > > Btw, comparing Struts and Cocoon, I must admit, that Struts has much
> more
> > > clear concepts and it's much easier in use and installation than Cocoon.
> The
> > > only thing that keeps me with C2 is that Struts has no XML/XSP/XSLT
> > > capabilities and almost all its features are only a subset of Cocoon's
> and
> > > can be easily implemented with C2.
> > >
> > > Best regards,
> > >
> > > Konstantin Piroumian
> > > Program Leader
> > >
> > > Protek Flagship LLC
> > > Phone: + 7 095 795 0520 (add. 1288)
> > > Fax: + 7 095 795 0525
> > > E-mail: kpiroumian@flagship.ru
> > > http://www.protek.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Action selection in sitemap
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> > Hi, C2ers!
> >
> > I've already asked this question and it seems that nobody could answer
it.
> > The question is: why the Environment interface has getAction() method
which
> > returns the value of 'cocoon-action' (hard-coded) parameter from the
> > request. It would be much better to be able to set the action name (or a
> > filter/pattern expression) in the sitemap. E.g.:
> >
> >
<skipped>
> > So, requests will be of this form:
> > /registration/Start - the StartProcessAction will be called
> > /registration/Input - InputAction
> > /registration/Cancel - CancelProcessAction
>
> Of course this is a way to go. Can you give an example if the actual
> action request is comming from a html button in a form (is encoded as a
> parameter instead of URI-path)?
The action request comes from different HTML forms but processed by the same
matcher "registration/*". Which button caused this submit in this case is
processed internally by the appropriate action.
After thinking a little more I came to this three ways of determining the
action:
1 an URL part (all buttons are processed by the action)
2 action parameter (like 'cocoon-action' - one param name - multiple
actions)
3 different parameters (e.g., three buttons with different names on a
form. It doesn't matter what the value is - we need to check if the
parameter is present)
The first case is useful when you have a single action for all buttons on a
form (e.g. the actual processing is performed on the back-end and you don't
care which button had been clicked, e.g. in an EJB or Workflow application).
The second case is currently used in C2, but the main disadvantage of it is
that you depend on the button value, which is an issue in a multilanguage
application (alternatively, a hidden field with JavaScript can be used -
this is not a good solution either)
The third case IMO is best: you have as many buttons as you like, and any
labels (values) - you only get one button on submit and you check which one
of the possible params is present.
So, I can suggest to improve C2 action selection mechanism to support all 3
cases. It seems to me that it will require some changes in interfaces and
not so easy to implement (from the first look).
Btw, 'cocoon-view' parameter name is also hard-coded. Maybe it'll be better
to invent some kind of a selection mechanism (instead of using sitemap
selectors) based on attributes for things that depend on request parameter
names, values and presence?
Regards,
Konstantin Piroumian
>
> And, yes, patches are welcome.
>
> Giacomo
>
> >
> > As you can see there is no need to use any '?cocoon-action=Start' or so
in
> > the request and IMO using 'registration/Start' is much better - you have
> > clean separation of posted data and the action. I think, it will be easy
to
> > implement, but requires changes to Environment interface (remove or
> > deprecate getAction()).
> >
> > The document that pushed me to this idea is related to Struts, but it
can
> > apply also to C2 application development as well:
> > http://husted.com/about/scaffolding/catalog.htm . Many good
> > advice/hints/tricks from it could be used in C2 too.
> >
> > Are there any comments on this or other ideas?
> >
> > Btw, comparing Struts and Cocoon, I must admit, that Struts has much
more
> > clear concepts and it's much easier in use and installation than Cocoon.
The
> > only thing that keeps me with C2 is that Struts has no XML/XSP/XSLT
> > capabilities and almost all its features are only a subset of Cocoon's
and
> > can be easily implemented with C2.
> >
> > Best regards,
> >
> > Konstantin Piroumian
> > Program Leader
> >
> > Protek Flagship LLC
> > Phone: + 7 095 795 0520 (add. 1288)
> > Fax: + 7 095 795 0525
> > E-mail: kpiroumian@flagship.ru
> > http://www.protek.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Action selection in sitemap
Posted by giacomo <gi...@apache.org>.
On Thu, 8 Nov 2001, Piroumian, Konstantin wrote:
> Hi, C2ers!
>
> I've already asked this question and it seems that nobody could answer it.
> The question is: why the Environment interface has getAction() method which
> returns the value of 'cocoon-action' (hard-coded) parameter from the
> request. It would be much better to be able to set the action name (or a
> filter/pattern expression) in the sitemap. E.g.:
>
> <!-- For a registration process we have three actions: start, user input
> processing, cancel -->
> <map:actions>
> <map:action name="start-process" src="regtest.StartProcessAction"/>
> <map:action name="input-process" src="regtest.InputAction"/>
> <map:action name="cancel-process" src="regtest.CancelProcessAction"/>
> </map:actions>
>
> <!-- The action set for the registration process -->
> <map:action-sets>
> <map:action-set name="registration-process">
> <map:act type="start-process" action="Start"/>
> <map:act type="input-process" action="Input"/>
> <map:act type="cancel-process" action="Cancel"/>
> </map:action-set>
> </map:action-sets>
>
> <!-- Entry point for all registration requests -->
> <map:match pattern="registration/*">
> <map:act-set type="registration-process" action="{1}">
> <map:read type="jsp" src="jsp/{current-page}.jsp"
> </map:act>
> <map:read src="html/error.htm"/>
> </map:match>
>
> So, requests will be of this form:
> /registration/Start - the StartProcessAction will be called
> /registration/Input - InputAction
> /registration/Cancel - CancelProcessAction
Of course this is a way to go. Can you give an example if the actual
action request is comming from a html button in a form (is encoded as a
parameter instead of URI-path)?
And, yes, patches are welcome.
Giacomo
>
> As you can see there is no need to use any '?cocoon-action=Start' or so in
> the request and IMO using 'registration/Start' is much better - you have
> clean separation of posted data and the action. I think, it will be easy to
> implement, but requires changes to Environment interface (remove or
> deprecate getAction()).
>
> The document that pushed me to this idea is related to Struts, but it can
> apply also to C2 application development as well:
> http://husted.com/about/scaffolding/catalog.htm . Many good
> advice/hints/tricks from it could be used in C2 too.
>
> Are there any comments on this or other ideas?
>
> Btw, comparing Struts and Cocoon, I must admit, that Struts has much more
> clear concepts and it's much easier in use and installation than Cocoon. The
> only thing that keeps me with C2 is that Struts has no XML/XSP/XSLT
> capabilities and almost all its features are only a subset of Cocoon's and
> can be easily implemented with C2.
>
> Best regards,
>
> Konstantin Piroumian
> Program Leader
>
> Protek Flagship LLC
> Phone: + 7 095 795 0520 (add. 1288)
> Fax: + 7 095 795 0525
> E-mail: kpiroumian@flagship.ru
> http://www.protek.com
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[C2] Action selection in sitemap
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
Hi, C2ers!
I've already asked this question and it seems that nobody could answer it.
The question is: why the Environment interface has getAction() method which
returns the value of 'cocoon-action' (hard-coded) parameter from the
request. It would be much better to be able to set the action name (or a
filter/pattern expression) in the sitemap. E.g.:
<!-- For a registration process we have three actions: start, user input
processing, cancel -->
<map:actions>
<map:action name="start-process" src="regtest.StartProcessAction"/>
<map:action name="input-process" src="regtest.InputAction"/>
<map:action name="cancel-process" src="regtest.CancelProcessAction"/>
</map:actions>
<!-- The action set for the registration process -->
<map:action-sets>
<map:action-set name="registration-process">
<map:act type="start-process" action="Start"/>
<map:act type="input-process" action="Input"/>
<map:act type="cancel-process" action="Cancel"/>
</map:action-set>
</map:action-sets>
<!-- Entry point for all registration requests -->
<map:match pattern="registration/*">
<map:act-set type="registration-process" action="{1}">
<map:read type="jsp" src="jsp/{current-page}.jsp"
</map:act>
<map:read src="html/error.htm"/>
</map:match>
So, requests will be of this form:
/registration/Start - the StartProcessAction will be called
/registration/Input - InputAction
/registration/Cancel - CancelProcessAction
As you can see there is no need to use any '?cocoon-action=Start' or so in
the request and IMO using 'registration/Start' is much better - you have
clean separation of posted data and the action. I think, it will be easy to
implement, but requires changes to Environment interface (remove or
deprecate getAction()).
The document that pushed me to this idea is related to Struts, but it can
apply also to C2 application development as well:
http://husted.com/about/scaffolding/catalog.htm . Many good
advice/hints/tricks from it could be used in C2 too.
Are there any comments on this or other ideas?
Btw, comparing Struts and Cocoon, I must admit, that Struts has much more
clear concepts and it's much easier in use and installation than Cocoon. The
only thing that keeps me with C2 is that Struts has no XML/XSP/XSLT
capabilities and almost all its features are only a subset of Cocoon's and
can be easily implemented with C2.
Best regards,
Konstantin Piroumian
Program Leader
Protek Flagship LLC
Phone: + 7 095 795 0520 (add. 1288)
Fax: + 7 095 795 0525
E-mail: kpiroumian@flagship.ru
http://www.protek.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SVG templates are broken XML
Posted by David Crossley <cr...@indexgeo.com.au>.
Carsten wrote:
> Hi David,
> what about using a different namespace for the label element?
There is nothing that can be done. Either the document validates
against the official DTD or it does not. There is no "label" element
in the SVG DTD.
David
> > -----Original Message-----
> > From: David Crossley [mailto:crossley@indexgeo.com.au]
> > Sent: Thursday, November 08, 2001 9:26 AM
> > To: cocoon-dev@xml.apache.org
> > Subject: SVG templates are broken XML
> >
> >
> > Hopefully this issue will go away when we get rid of
> > the side-bar image buttons. However, it may indicate
> > some other issue, so i will raise it again.
> >
> > See background info at issue 4) below. Basically, the
> > svg template files at documentation/svg/*.xml are all
> > broken according to the svg10.dtd, mainly because they
> > have an extra <label> element inside the <text> element.
> >
> > This has drastic effect when you try to declare the
> > SVG DTD and then do "build docs". Here is the resultant
> > error message ...
> > --------------
> > FATAL_E 10050 [ ] (): Error in TraxTransformer:
> > javax.xml.transform.TransformerException: The current
> > document is unable to create an element of the requested
> > type (namespace: http://www.w3.org/2000/svg, name: label).
> > --------------
> >
> > The full cocoon.log is attached.
> > --David
> >
> > > Date: Sat, 3 Nov 2001 01:03:09 +1100
> > > Subject: XML validation during build docs
> > > From: David Crossley <cr...@indexgeo.com.au>
> > >
> > > OK, i have XML validation working now during build docs.
> > > It revealed some validation errors - nothing too drastic.
> > > I have mended all the broken xdocs.
> > >
> > > These are the steps that i took to get it going. Basically
> > > every XML instance document must declare its ruleset.
> > > Step 4 is a worry and we need to resolve it. The rest can
> > > be committed when ready.
> > >
> > > 1) in cocoon.xconf set the parser parameter "validate"
> > >
> > > 2) add initial internal DTD to both *.roles config files
> > >
> > > 3) add an initial external DTD for book.xml documents
> > > and add a Declaration to each */book.xml
> > > ... is there a proper DTD somewhere?
> > >
> > > 4) declare the DTD for each SVG template in
> > > documentation/svg/*.xml
> > > I got the final release svg10.dtd from W3C. However,
> > > i encountered some serious issues. Our SVG files are
> > > broken according to the SVG DTD ...
> > > a) We have an extra "label" element inside the "text"
> > > element, which is not allowed by the DTD.
> > > b) There is no attribute "xmlns:xlink" for the svg element,
> > > yet our files have that.
> > >
> > > As a workaround to get the rest of the validation run
> > > happening, i have written a minimal svg DTD based on
> > > those simple XML files to reflect their current structure.
> > >
> > > --David
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: SVG templates are broken XML
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi David,
what about using a different namespace for the label element?
Carsten
> -----Original Message-----
> From: David Crossley [mailto:crossley@indexgeo.com.au]
> Sent: Thursday, November 08, 2001 9:26 AM
> To: cocoon-dev@xml.apache.org
> Subject: SVG templates are broken XML
>
>
> Hopefully this issue will go away when we get rid of
> the side-bar image buttons. However, it may indicate
> some other issue, so i will raise it again.
>
> See background info at issue 4) below. Basically, the
> svg template files at documentation/svg/*.xml are all
> broken according to the svg10.dtd, mainly because they
> have an extra <label> element inside the <text> element.
>
> This has drastic effect when you try to declare the
> SVG DTD and then do "build docs". Here is the resultant
> error message ...
> --------------
> FATAL_E 10050 [ ] (): Error in TraxTransformer:
> javax.xml.transform.TransformerException: The current
> document is unable to create an element of the requested
> type (namespace: http://www.w3.org/2000/svg, name: label).
> --------------
>
> The full cocoon.log is attached.
> --David
>
> > Date: Sat, 3 Nov 2001 01:03:09 +1100
> > Subject: XML validation during build docs
> > From: David Crossley <cr...@indexgeo.com.au>
> >
> > OK, i have XML validation working now during build docs.
> > It revealed some validation errors - nothing too drastic.
> > I have mended all the broken xdocs.
> >
> > These are the steps that i took to get it going. Basically
> > every XML instance document must declare its ruleset.
> > Step 4 is a worry and we need to resolve it. The rest can
> > be committed when ready.
> >
> > 1) in cocoon.xconf set the parser parameter "validate"
> >
> > 2) add initial internal DTD to both *.roles config files
> >
> > 3) add an initial external DTD for book.xml documents
> > and add a Declaration to each */book.xml
> > ... is there a proper DTD somewhere?
> >
> > 4) declare the DTD for each SVG template in
> > documentation/svg/*.xml
> > I got the final release svg10.dtd from W3C. However,
> > i encountered some serious issues. Our SVG files are
> > broken according to the SVG DTD ...
> > a) We have an extra "label" element inside the "text"
> > element, which is not allowed by the DTD.
> > b) There is no attribute "xmlns:xlink" for the svg element,
> > yet our files have that.
> >
> > As a workaround to get the rest of the validation run
> > happening, i have written a minimal svg DTD based on
> > those simple XML files to reflect their current structure.
> >
> > --David
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
SVG templates are broken XML
Posted by David Crossley <cr...@indexgeo.com.au>.
Hopefully this issue will go away when we get rid of
the side-bar image buttons. However, it may indicate
some other issue, so i will raise it again.
See background info at issue 4) below. Basically, the
svg template files at documentation/svg/*.xml are all
broken according to the svg10.dtd, mainly because they
have an extra <label> element inside the <text> element.
This has drastic effect when you try to declare the
SVG DTD and then do "build docs". Here is the resultant
error message ...
--------------
FATAL_E 10050 [ ] (): Error in TraxTransformer:
javax.xml.transform.TransformerException: The current
document is unable to create an element of the requested
type (namespace: http://www.w3.org/2000/svg, name: label).
--------------
The full cocoon.log is attached.
--David
> Date: Sat, 3 Nov 2001 01:03:09 +1100
> Subject: XML validation during build docs
> From: David Crossley <cr...@indexgeo.com.au>
>
> OK, i have XML validation working now during build docs.
> It revealed some validation errors - nothing too drastic.
> I have mended all the broken xdocs.
>
> These are the steps that i took to get it going. Basically
> every XML instance document must declare its ruleset.
> Step 4 is a worry and we need to resolve it. The rest can
> be committed when ready.
>
> 1) in cocoon.xconf set the parser parameter "validate"
>
> 2) add initial internal DTD to both *.roles config files
>
> 3) add an initial external DTD for book.xml documents
> and add a Declaration to each */book.xml
> ... is there a proper DTD somewhere?
>
> 4) declare the DTD for each SVG template in
> documentation/svg/*.xml
> I got the final release svg10.dtd from W3C. However,
> i encountered some serious issues. Our SVG files are
> broken according to the SVG DTD ...
> a) We have an extra "label" element inside the "text"
> element, which is not allowed by the DTD.
> b) There is no attribute "xmlns:xlink" for the svg element,
> yet our files have that.
>
> As a workaround to get the rest of the validation run
> happening, i have written a minimal svg DTD based on
> those simple XML files to reflect their current structure.
>
> --David
Re: [VOTE] XML validation during build docs
Posted by Stefano Mazzocchi <st...@apache.org>.
David Crossley wrote:
>
> I would like to enable XML validation by default during
> the "build docs". This is effected by setting the
> parameter "validate=true" in the <parser> entry of
> src/documentation/cocoon.xconf
>
> I have been running my local "build docs" like this for a
> long time - it works well. (Consequently i seem to be the only
> one who attends to the various xdocs validation errors :-)
>
> Note that in this thread we are only talking about validation
> of xdocs/*.xml documentation. Validation of configuration files
> such as */sitemap.xmap and */cocoon.xconf are another
> matter which needs to be addressed separately.
>
> I consider it to be vital that the Cocoon distributions go out
> with a guaranteed valid set of XML documents. An exemplary
> XML framework needs to be spotless.
>
> So here is my +1 for default validation of xdocs.
Absolutely +1
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] XML validation during build docs
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> David Crossley wrote:
> >...
> > I consider it to be vital that the Cocoon distributions go out
> > with a guaranteed valid set of XML documents. An exemplary
> > XML framework needs to be spotless.
> >
> > So here is my +1 for default validation of xdocs.
>
> +1
+1
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] XML validation during build docs
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
David Crossley wrote:
>...
> I consider it to be vital that the Cocoon distributions go out
> with a guaranteed valid set of XML documents. An exemplary
> XML framework needs to be spotless.
>
> So here is my +1 for default validation of xdocs.
+1
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[VOTE] XML validation during build docs
Posted by David Crossley <cr...@indexgeo.com.au>.
I would like to enable XML validation by default during
the "build docs". This is effected by setting the
parameter "validate=true" in the <parser> entry of
src/documentation/cocoon.xconf
I have been running my local "build docs" like this for a
long time - it works well. (Consequently i seem to be the only
one who attends to the various xdocs validation errors :-)
Note that in this thread we are only talking about validation
of xdocs/*.xml documentation. Validation of configuration files
such as */sitemap.xmap and */cocoon.xconf are another
matter which needs to be addressed separately.
I consider it to be vital that the Cocoon distributions go out
with a guaranteed valid set of XML documents. An exemplary
XML framework needs to be spotless.
So here is my +1 for default validation of xdocs.
--David Crossley
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XML validation during build docs
Posted by David Crossley <cr...@indexgeo.com.au>.
OK, i have XML validation working now during build docs.
It revealed some validation errors - nothing too drastic.
I have mended all the broken xdocs.
These are the steps that i took to get it going. Basically
every XML instance document must declare its ruleset.
Step 4 is a worry and we need to resolve it. The rest can
be committed when ready.
1) in cocoon.xconf set the parser parameter "validate"
2) add initial internal DTD to both *.roles config files
3) add an initial external DTD for book.xml documents
and add a Declaration to each */book.xml
... is there a proper DTD somewhere?
4) declare the DTD for each SVG template in
documentation/svg/*.xml
I got the final release svg10.dtd from W3C. However,
i encountered some serious issues. Our SVG files are
broken according to the SVG DTD ...
a) We have an extra "label" element inside the "text"
element, which is not allowed by the DTD.
b) There is no attribute "xmlns:xlink" for the svg element,
yet our files have that.
As a workaround to get the rest of the validation run
happening, i have written a minimal svg DTD based on
those simple XML files to reflect their current structure.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XML validation during build docs
Posted by David Crossley <cr...@indexgeo.com.au>.
Carsten wrote:
> Hi David,
>
> I just updated the JaxpParser of 2.1 to be configurable. Currently
> you can turn on validation by specifying the parser in the cocoon.xconf
> and add a parameter: <parameter name="validate" value="true"/> to the
> configuration. This is the good news.
Excellent. I tweaked the documentation/cocoon.xconf
and validation works as expected.
> The bad news is: now all xml documents are validated. Whereas this seems
> great in the first run, you now need a dtd for every document as
> the errorhandler for the parser always throws an exception if
> the document cannot be validated.
I think good news on both fronts. Cocoon needs to be able
to rely on its own config files, documentation, and samples.
Good news because it forces us to create a reliable framework.
> So, we need a dtd for the book.xml documents and this should
> work then for the documentation build.
I have jumped the first validation hurdles by writing quick-and-dirty
internal DTDs for ...
src/org/apache/cocoon/cocoon.roles
src/org/apache/cocoon/sitemap/sitemap.roles
documentation/xdocs/book.xml
... that enabled the validation run to start.
That brought up more issues with other documents that do
not declare their structure, e.g. documentation/svg/header.xml
(Anyway, it is a journey.)
The next issue would be for cocoon.xconf and sitemap.xmap
There is an initial "sitemap.dtd" dated 2001-07-15
I do not know its status.
--David
> Carsten
>
> David Crossley wrote:
> >
> > Has the "build docs" stopped doing validation of xdocs, or
> > do i imagine that? I recall that when the build was controlled
> > by Ant, then it was doing full XML validation. I am sure that
> > i often received validation errors while developing my xdocs.
> >
> > Now that the build is run by Cocoon then it only does a
> > well-formedness check. I tested the current situation by
> > deliberately breaking index.xml by removing the mandatory
> > <title> element, then by just removing the closing tag.
> >
> > I think that i know why. The Ant build used Xerces directly
> > where validation was probably default true. Whereas, in
> > Cocoon the parser should, and does, have validation=false.
> >
> > I see that components/parser/XercesParser.java has
> > setFeature validation=false. However, the default
> > JaxpParser.java does not setFeature validation in any way.
> >
> > I would think it desible to have validation happening for
> > the documentation build, and of course, not happening
> > while running as a servlet. Is there a way?
> >
> > --David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XML validation during build docs
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi David,
I just updated the JaxpParser of 2.1 to be configurable. Currently
you can turn on validation by specifying the parser in the cocoon.xconf
and add a parameter: <parameter name="validate" value="true"/> to the
configuration. This is the good news.
The bad news is: now all xml documents are validated. Whereas this seems
great in the first run, you now need a dtd for every document as
the errorhandler for the parser always throws an exception if
the document cannot be validated.
So, we need a dtd for the book.xml documents and this should
work then for the documentation build.
Carsten
David Crossley wrote:
>
> Has the "build docs" stopped doing validation of xdocs, or
> do i imagine that? I recall that when the build was controlled
> by Ant, then it was doing full XML validation. I am sure that
> i often received validation errors while developing my xdocs.
>
> Now that the build is run by Cocoon then it only does a
> well-formedness check. I tested the current situation by
> deliberately breaking index.xml by removing the mandatory
> <title> element, then by just removing the closing tag.
>
> I think that i know why. The Ant build used Xerces directly
> where validation was probably default true. Whereas, in
> Cocoon the parser should, and does, have validation=false.
>
> I see that components/parser/XercesParser.java has
> setFeature validation=false. However, the default
> JaxpParser.java does not setFeature validation in any way.
>
> I would think it desible to have validation happening for
> the documentation build, and of course, not happening
> while running as a servlet. Is there a way?
>
> --David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org