You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2002/03/15 18:26:56 UTC
Dynamic Schematron validation works!
Dear All,
Encouraged by Ivelin Ivanov's work, I tried to see if the XSLT generated by
Schematron could be dynamically generated.
It can!
Here were my test pipelines (using all Ivelin's files):
Using a pre-made validating XSLT:
<map:match pattern="static-validation">
<map:generate src="schematron/some-xmlform.xml"/>
<map:transform src="schematron/xmlform-sch-report.xsl"/>
<map:serialize type="xml"/>
</map:match>
Using a validating XSLT, generated by another pipeline:
<map:match pattern="dynamic-validation">
<map:generate src="schematron/some-xmlform.xml"/>
<map:transform src="cocoon:/make-validator"/>
<map:serialize type="xml"/>
</map:match>
A pipeline for generating validating XSLT:
<map:match pattern="make-validator">
<map:generate src="schematron/xmlform-sch-report.xml"/>
<map:transform src="schematron/xmlform-schematron.xsl"/>
<map:serialize type="xml"/>
</map:match>
Apart from having to comment out a reference to <saxon:output/> in
'wrappers.xsl' it all worked fine.
I viewed this with MSIE 5, the xml was the same as the samples.
Cool!
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Dynamic Schematron validation works!
Posted by Ivelin Ivanov <iv...@iname.com>.
Thank you Jeremy !
One more step ahead.
Let's get a nice wizard complete now!
----- Original Message -----
From: "Jeremy Quinn" <je...@media.demon.co.uk>
To: "Cocoon Dev" <co...@xml.apache.org>
Sent: Friday, March 15, 2002 11:26 AM
Subject: Dynamic Schematron validation works!
> Dear All,
>
> Encouraged by Ivelin Ivanov's work, I tried to see if the XSLT generated
by
> Schematron could be dynamically generated.
>
> It can!
>
> Here were my test pipelines (using all Ivelin's files):
>
>
> Using a pre-made validating XSLT:
>
> <map:match pattern="static-validation">
> <map:generate src="schematron/some-xmlform.xml"/>
> <map:transform src="schematron/xmlform-sch-report.xsl"/>
> <map:serialize type="xml"/>
> </map:match>
>
> Using a validating XSLT, generated by another pipeline:
>
> <map:match pattern="dynamic-validation">
> <map:generate src="schematron/some-xmlform.xml"/>
> <map:transform src="cocoon:/make-validator"/>
> <map:serialize type="xml"/>
> </map:match>
>
> A pipeline for generating validating XSLT:
>
> <map:match pattern="make-validator">
> <map:generate src="schematron/xmlform-sch-report.xml"/>
> <map:transform src="schematron/xmlform-schematron.xsl"/>
> <map:serialize type="xml"/>
> </map:match>
>
>
> Apart from having to comment out a reference to <saxon:output/> in
> 'wrappers.xsl' it all worked fine.
>
> I viewed this with MSIE 5, the xml was the same as the samples.
>
>
> Cool!
>
>
> regards Jeremy
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
>
> ---------------------------------------------------------------------
> 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: Dynamic Schematron validation works!
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 6:01 pm +0100 16/3/02, Michael Hartle wrote:
>Jeremy Quinn wrote:
>
>>At 11:49 am +0100 16/3/02, Torsten Curdt wrote:
>>
>>>Jeremy, I don't want to spoil your enthusiasm but there still two major
>>>issues... I've been talking with Ivelin off the list about these issues.
>>>(Maybe we should move our discussion to the list?!)
>>>
>>>1) current binding prohibits the use of checkboxes (good old checkbox
>>> problem *sigh*) You cannot turn the checkbox off via request.
>>>
>>
>>I am taking a different approach, it should not be a problem in
>><slash-edit/>; you have to supply (very simple) StyleSheet snippets to
>>convert _your_ incoming request data into an instance to be validated.
>>
>>This gives you the opportunity to detect a missing field (un-checked box),
>>because your StyleSheet should know about it.
>>
>After digging through the sunShine/sunRise/sunSpot documentation, I got
>curious: is your work somehow related to the sunShine session contexts
>or the sunRise authentication ?
no, but I'd like to integrate authentication into slash-edit at some time.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Dynamic Schematron validation works!
Posted by Michael Hartle <mh...@hartle-klug.com>.
Jeremy Quinn wrote:
>At 11:49 am +0100 16/3/02, Torsten Curdt wrote:
>
>>Jeremy, I don't want to spoil your enthusiasm but there still two major
>>issues... I've been talking with Ivelin off the list about these issues.
>>(Maybe we should move our discussion to the list?!)
>>
>>1) current binding prohibits the use of checkboxes (good old checkbox
>> problem *sigh*) You cannot turn the checkbox off via request.
>>
>
>I am taking a different approach, it should not be a problem in
><slash-edit/>; you have to supply (very simple) StyleSheet snippets to
>convert _your_ incoming request data into an instance to be validated.
>
>This gives you the opportunity to detect a missing field (un-checked box),
>because your StyleSheet should know about it.
>
After digging through the sunShine/sunRise/sunSpot documentation, I got
curious: is your work somehow related to the sunShine session contexts
or the sunRise authentication ?
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Web Wizard Best Practices
Posted by Sam Robertson <xm...@yahoo.com>.
So Ivelin, if I understand you correctly,
are you suggesting that we would have two points of
validation?
1) when the user submits a form via 'action'.
2) when the information stored in the db (or wherever)
is displayed to the user using transformation
validation.
Well for (2), I'm not clear on why validation is
needed.
The user hasn't even had a chance to do anything with
the information presented to him/her. If the
information was maintained in the database, it would
need to be valid (I hope). If some business logic
changed later on, then at the time that the user
submits the form, the validation would take place,
wouldn't it? Why would we need another validation
before the submission?
I'm having a lot of difficulty understanding where to
place validation when dealing with XML databases like
Xindice. I would think that it should only be in one
place. So in your example, whether or not an email
address EXISTS in the xml database OR whether the
email address entered is VALID -- should happen in one
place. AFAIU, currently no such unique constraint
validation is offered by these databases. If anyone
knows otherwise, please let me know. So in this case,
I would have to get all email addresses in the xml
documents into a hash or use some DOM API during the
'action', then make sure that the new one that is
being inserted doesn't already exist. Then perform
the insert using the XMLDBTransformer.
Well wouldn't it be really cool (and faster!) if I
could do both the unique key validation and the insert
in one place?
Sorry if this email leans more towards xml databases.
I need some help clearing these concepts and
especially why something like this doesn't already
exist so please go easy on me.
Ivelin, I have tried your new xmlform example and it
rocks! Waiting to see Torsten's examples now.
Regards,
Sam
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Web Wizard Best Practices
Posted by Ivelin Ivanov <iv...@iname.com>.
Jeremy,
I've tried your latest piece of work. I think C2 needs more demos like
<slash-edit/> .
As I was looking through the code I realized that earlier I might have been
trying to fit one hat to all sizes.
Oh, didn't you say just that ;->
All right, having that said though, I still believe that both transofmation
validation and action validation can work together.
Consider the following scenario:
Let's say we're doing a cocoon feedback wizard (proposed by Torsten), where
the developer enters feedback information on the first one or two pages and
fills in contact information on the last page.
Welcome -> Fist feedback page -> Second Feedback Page -> Contact
Information -> Done
Now lets assume that the last page has the form:
<contactInfo>
<name/>
<email/>
<telephone/>
<address/>
</contactInfo>
Of these only name and email are mandatory.
When a new user goes through the wizard he/she will complete each page and
press the Next button on the wizard.
I would think that the validation on each page would be done by the Action
handling the form using Schematron (read: XSD, Relax-NG, Schematron, DTD or
whatever other Standard XML validation schema is preferred) document and
application specific business logic (like: does the db have a record of the
same email already entered by someone else, if so, ask the user to either
login or enter another email).
Of course the result of the action validation will either take the user to
the next page or the same one with highlited errors.
Now consider that an existing user is logged in and decides to fill in a new
feedback form.
The steps for the feedback pages are the same. The interesting part is the
last one which is supposed to ask the user for contact information. Since
the user has already been registered and is logged in the system, the
contact information will be prepopulated, expecting the user to eventually
just edit some of the fields or leave them unchanged.
Now lets assume that between the user's registration and the current
feedback wizard a business rule was changed in the system. Not only the name
and email, but now the telephone is a mandatory field.
Well in this case I think that a Schematron validation in the pipe which
loads the contact info from the db and displays it in the HTML page is more
appropriate. This way the user has a chance to see the new business rule,
Before submitting the form.
Ok, now what was my point.
1) Only one validating schema document was used for both scenarious.
2) It was applied at the appropriate points in the system, depending on the
circumstances. This flexibility allows the Action to apply not only the
Schematron validation but also an additional business logic rule. Such
business rule is specific to the database entry point, but makes no sence
for the data extraction pipe.
3) Applying the validation Before the data enters the database as well as
after it is Extracted, helps maintain a correct implementation of the
read/write business logic. Such validation practices can be particularly
useful during development.
It's almost like taking the good old assert (or Eiffel pre/post) keyword to
the next level.
Since there are plenty of comlex validation scenarious in the real world,
extending the pipeline functionality to allow for validation branching will
blur the line between logic, content and presentation, that the sitemap is
intendet to control in the first place.
(This last sentence is like shooting myself in the foot :>. Although I'm
still not sure that a simplified XPath selector component wouldn't be
useful)
Does this make any sence ?
Cheers,
Ivelin
----- Original Message -----
From: "Jeremy Quinn" <je...@media.demon.co.uk>
To: <co...@xml.apache.org>
Sent: Sunday, March 17, 2002 4:02 PM
Subject: Re: [RT] Web Wizard Best Practices [was: Dynamic Schematron
validation works!]
> At 11:40 am -0600 17/3/02, Ivelin Ivanov wrote:
> >Jeremy,
> >> Not wanting to be negative or anything ... but we have quite different
> >> approaches driven by different needs, we may or may not be able to
> >> reconcile them.
> >
> >That's perfectly fine with me.
> >Don't you think we should be able to agree on a problem that satisfies a
> >common subset of our real world scenarious which may be quite different
for
> >everyone.
> >We can still end up with to 2 different possible solutions and offer
these
> >as two alternative patterns.
> >My issue with the current stage with C2 is that there are no best
practices
> >documents.
> >Most recently successful technologies have these documents which improve
> >their popularity and recognition by helping developers be more
productive.
>
> I agree, I ought to be able to do that ..... it's just I am turning the
> project on it's head at least once a day ..... still experimenting too
much
>
> >> It does not really matter right now, we will _all_ learn from both
> >attempts
> >
> >That's one certain thing !
>
> That's how cocoon has grow
>
> >> What I mean more specifically:
> >>
> >> As I understand it .... you re trying to make a generic system
(partially
> >> influenced by previous work done attempting to implement the XForms
> >> standard) for building complex business objects.
> >>
> >> Furthermore you are trying to make your _sitemap_ adapt itself to the
> >> progress of the transaction.
> >
> >Actually Torsten has a stronger view on this approach.
> >I mostly agree with his ideas, though there are a few things we'll need
to
> >iron out in the coming days.
> >
> >I definitely want to understand your technique though. Don't want to rush
> >into a dead end street.
>
> You don't have a dead end street, the direction Torsten is going in could
> lead to new ways of using Cocoon, just as much as mine might ;)
>
> >I'm mostly driven by the fast developments in the web services area.
> >Having faced an actual problem of converting a complex Web UI portal into
> >one that offers almost all of its UI functionality through web services,
I
> >know that this turned out to be very hard while it could have been real
> >easy.
> >
> >My humble vision is that in the near future successful web-app servers
will
> >be
> >able to seamlessly integrate with web services. Web services already know
> >how to handle xml <-> object binding.
>
> Well that's cool stuff
>
> >Cocoon is a mature and sophisticated container and its future will be
even
> >brighter if it allows for existing Web UI portals to offer their
> >functionality through web services with minimal investment.
>
> Cocoon is much more mature as a publishing engine than a webapp engine.
>
> >> I on the other hand am trying to make generic patterns for assembling
> >> sitemap and XSLT components, as an example of how to add the ability to
> >> edit your own existing assets, to an existing publishing project.
> >
> >I find this exciting and would certainly like to follow the development.
> >While working on these patterns I assume you will try to keep the lines
> >between presentation, content and logic bright and sharp.
> >
> >>
> >> What's more, I am implementing my logic differently; by having
> >transformers
> >> modify the _content_ of the pipeline to adapt to the progress of the
> >> transaction.
> >>
> >> Both techniques are very interesting in their own right!
> >
> >Have you checked this in? Where should I look?
>
> it's in cvs now
>
> >> If I had access to the stuff you are doing now, 12 months ago, I'd be
> >> dancing in the streets! It was JUST what I wanted for the Crudlet
project
> >I
> >> was working on, where we had large and complex JavaBeans to fill in and
> >> manipulate, requiring multiple forms to do the job.
> >
> >I came across Crudlets recently and found it interesting, but it seemed
like
> >there was no activity for quite a while.
> >What is the current status?
>
> May she RIP
>
> >> If you were to follow my pattern (which I am not suggesting, this is
just
> >> an illustration) you would:
> >>
> >> 1. Generate an Instance
> >> using XSP or RequestGenerator + XSLT etc.
> >>
> >> 2. Validate the Instance.
> >> using the delightful Schematron (thanks!)
> >
> >so far so good.
> >
> >>
> >> 3. Adapt the Instance (depending on validation result) into tags for a
> >> CastorTransformer, which makes/modifies/prods your bean.
> >
> >The CastorTransformer marshalls a JavaBean into XML document. Currently
it
> >only "prods" but does not "make/modify".
>
> Sorry, that should have been makes/modifies/prods/reads :)
>
> >How would you bind the XML data from 2. into JavaBeans in the business
> >domain?
>
> By un-marshalling the xml (you have just generated and validated) in (a
> new) CastorTransformer, specifying a mapping if required.
>
> The CastorTransformer would act either as a producer or a consumer of XML,
> depending on what tags were in it's stream.
>
> Writing XML un-marshals to a a Bean, Reading XML marshals from the Bean.
> Something else invokes methods on the Bean.
>
> You ought to be able to make/do/destroy any number of objects all on the
> same pass of the Transformer if you need to .... by having multiple castor
> tags in the stream.
>
> Even (Sylvain, you listening? ;) implement Castor access as a
> WriteableSource instead of a Transformer, you make up a psuedo protocol to
> read, write, prod.
>
> >> 4. Adapt the Instance (depending on Castor result) into whatever your
next
> >> stage needs to be
> >
> >I assume you mean adapt through XSLT ?
>
> Yes
>
> >> I do not think we are duplicating effort.
> >> I think both of these efforts will (at the very least) prove to be
useful
> >> examples for other developers, regardless of the final outcome.
> >>
> >> As long as we keep sharing our ideas publicly (as has happened to great
> >> effect so far!) we have a win-win situation.
> >>
> >> I am not convinced that one pattern can solve every problem in this
realm
> >> .... there is still a lot to explore ....
> >
> >Definitely.
> >Let's keep it moving and close the subject this time.
> >It would be sad to see this discussion dead end like the other ones which
> >tried to tackle the same problem in the last 2 years.
>
>
> +1
>
> regards Jeremy
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
>
> ---------------------------------------------------------------------
> 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: [RT] Web Wizard Best Practices [was: Dynamic Schematron
validation works!]
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 11:40 am -0600 17/3/02, Ivelin Ivanov wrote:
>Jeremy,
>> Not wanting to be negative or anything ... but we have quite different
>> approaches driven by different needs, we may or may not be able to
>> reconcile them.
>
>That's perfectly fine with me.
>Don't you think we should be able to agree on a problem that satisfies a
>common subset of our real world scenarious which may be quite different for
>everyone.
>We can still end up with to 2 different possible solutions and offer these
>as two alternative patterns.
>My issue with the current stage with C2 is that there are no best practices
>documents.
>Most recently successful technologies have these documents which improve
>their popularity and recognition by helping developers be more productive.
I agree, I ought to be able to do that ..... it's just I am turning the
project on it's head at least once a day ..... still experimenting too much
>> It does not really matter right now, we will _all_ learn from both
>attempts
>
>That's one certain thing !
That's how cocoon has grow
>> What I mean more specifically:
>>
>> As I understand it .... you re trying to make a generic system (partially
>> influenced by previous work done attempting to implement the XForms
>> standard) for building complex business objects.
>>
>> Furthermore you are trying to make your _sitemap_ adapt itself to the
>> progress of the transaction.
>
>Actually Torsten has a stronger view on this approach.
>I mostly agree with his ideas, though there are a few things we'll need to
>iron out in the coming days.
>
>I definitely want to understand your technique though. Don't want to rush
>into a dead end street.
You don't have a dead end street, the direction Torsten is going in could
lead to new ways of using Cocoon, just as much as mine might ;)
>I'm mostly driven by the fast developments in the web services area.
>Having faced an actual problem of converting a complex Web UI portal into
>one that offers almost all of its UI functionality through web services, I
>know that this turned out to be very hard while it could have been real
>easy.
>
>My humble vision is that in the near future successful web-app servers will
>be
>able to seamlessly integrate with web services. Web services already know
>how to handle xml <-> object binding.
Well that's cool stuff
>Cocoon is a mature and sophisticated container and its future will be even
>brighter if it allows for existing Web UI portals to offer their
>functionality through web services with minimal investment.
Cocoon is much more mature as a publishing engine than a webapp engine.
>> I on the other hand am trying to make generic patterns for assembling
>> sitemap and XSLT components, as an example of how to add the ability to
>> edit your own existing assets, to an existing publishing project.
>
>I find this exciting and would certainly like to follow the development.
>While working on these patterns I assume you will try to keep the lines
>between presentation, content and logic bright and sharp.
>
>>
>> What's more, I am implementing my logic differently; by having
>transformers
>> modify the _content_ of the pipeline to adapt to the progress of the
>> transaction.
>>
>> Both techniques are very interesting in their own right!
>
>Have you checked this in? Where should I look?
it's in cvs now
>> If I had access to the stuff you are doing now, 12 months ago, I'd be
>> dancing in the streets! It was JUST what I wanted for the Crudlet project
>I
>> was working on, where we had large and complex JavaBeans to fill in and
>> manipulate, requiring multiple forms to do the job.
>
>I came across Crudlets recently and found it interesting, but it seemed like
>there was no activity for quite a while.
>What is the current status?
May she RIP
>> If you were to follow my pattern (which I am not suggesting, this is just
>> an illustration) you would:
>>
>> 1. Generate an Instance
>> using XSP or RequestGenerator + XSLT etc.
>>
>> 2. Validate the Instance.
>> using the delightful Schematron (thanks!)
>
>so far so good.
>
>>
>> 3. Adapt the Instance (depending on validation result) into tags for a
>> CastorTransformer, which makes/modifies/prods your bean.
>
>The CastorTransformer marshalls a JavaBean into XML document. Currently it
>only "prods" but does not "make/modify".
Sorry, that should have been makes/modifies/prods/reads :)
>How would you bind the XML data from 2. into JavaBeans in the business
>domain?
By un-marshalling the xml (you have just generated and validated) in (a
new) CastorTransformer, specifying a mapping if required.
The CastorTransformer would act either as a producer or a consumer of XML,
depending on what tags were in it's stream.
Writing XML un-marshals to a a Bean, Reading XML marshals from the Bean.
Something else invokes methods on the Bean.
You ought to be able to make/do/destroy any number of objects all on the
same pass of the Transformer if you need to .... by having multiple castor
tags in the stream.
Even (Sylvain, you listening? ;) implement Castor access as a
WriteableSource instead of a Transformer, you make up a psuedo protocol to
read, write, prod.
>> 4. Adapt the Instance (depending on Castor result) into whatever your next
>> stage needs to be
>
>I assume you mean adapt through XSLT ?
Yes
>> I do not think we are duplicating effort.
>> I think both of these efforts will (at the very least) prove to be useful
>> examples for other developers, regardless of the final outcome.
>>
>> As long as we keep sharing our ideas publicly (as has happened to great
>> effect so far!) we have a win-win situation.
>>
>> I am not convinced that one pattern can solve every problem in this realm
>> .... there is still a lot to explore ....
>
>Definitely.
>Let's keep it moving and close the subject this time.
>It would be sad to see this discussion dead end like the other ones which
>tried to tackle the same problem in the last 2 years.
+1
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Web Wizard Best Practices [was: Dynamic Schematron validation works!]
Posted by Ivelin Ivanov <iv...@iname.com>.
Jeremy,
----- Original Message -----
From: "Jeremy Quinn" <je...@media.demon.co.uk>
To: <co...@xml.apache.org>
Sent: Sunday, March 17, 2002 4:47 AM
Subject: Re: Dynamic Schematron validation works!
> At 1:23 pm -0600 16/3/02, Ivelin Ivanov wrote:
> >As Torsten suggested, shall we please try to agree on the requirements
for
> >the problem we're trying to solve.
> >Starting with something non-trivial, but not too comlex as well. Just
enough
> >to demonstrate good potential and allow for further extension.
>
>
> Hi Ivelin,
>
> Not wanting to be negative or anything ... but we have quite different
> approaches driven by different needs, we may or may not be able to
> reconcile them.
That's perfectly fine with me.
Don't you think we should be able to agree on a problem that satisfies a
common subset of our real world scenarious which may be quite different for
everyone.
We can still end up with to 2 different possible solutions and offer these
as two alternative patterns.
My issue with the current stage with C2 is that there are no best practices
documents.
Most recently successful technologies have these documents which improve
their popularity and recognition by helping developers be more productive.
> It does not really matter right now, we will _all_ learn from both
attempts
That's one certain thing !
> What I mean more specifically:
>
> As I understand it .... you re trying to make a generic system (partially
> influenced by previous work done attempting to implement the XForms
> standard) for building complex business objects.
>
> Furthermore you are trying to make your _sitemap_ adapt itself to the
> progress of the transaction.
Actually Torsten has a stronger view on this approach.
I mostly agree with his ideas, though there are a few things we'll need to
iron out in the coming days.
I definitely want to understand your technique though. Don't want to rush
into a dead end street.
I'm mostly driven by the fast developments in the web services area.
Having faced an actual problem of converting a complex Web UI portal into
one that offers almost all of its UI functionality through web services, I
know that this turned out to be very hard while it could have been real
easy.
My humble vision is that in the near future successful web-app servers will
be
able to seamlessly integrate with web services. Web services already know
how to handle xml <-> object binding.
Web services have their WSFL - a standard flow control language.
http://xml.coverpages.org/wsfl.html
And lately there is the WSRP initiative which strives to bind Web UI to Web
Services.
http://xml.coverpages.org/ni2002-01-21-b.html
Those who have tried WebLogic 7.0 Cajun or similar IDEs, should have noticed
where things might be going.
Cocoon is a mature and sophisticated container and its future will be even
brighter if it allows for existing Web UI portals to offer their
functionality through web services with minimal investment.
> I on the other hand am trying to make generic patterns for assembling
> sitemap and XSLT components, as an example of how to add the ability to
> edit your own existing assets, to an existing publishing project.
I find this exciting and would certainly like to follow the development.
While working on these patterns I assume you will try to keep the lines
between presentation, content and logic bright and sharp.
>
> What's more, I am implementing my logic differently; by having
transformers
> modify the _content_ of the pipeline to adapt to the progress of the
> transaction.
>
> Both techniques are very interesting in their own right!
Have you checked this in? Where should I look?
> If I had access to the stuff you are doing now, 12 months ago, I'd be
> dancing in the streets! It was JUST what I wanted for the Crudlet project
I
> was working on, where we had large and complex JavaBeans to fill in and
> manipulate, requiring multiple forms to do the job.
I came across Crudlets recently and found it interesting, but it seemed like
there was no activity for quite a while.
What is the current status?
> If you were to follow my pattern (which I am not suggesting, this is just
> an illustration) you would:
>
> 1. Generate an Instance
> using XSP or RequestGenerator + XSLT etc.
>
> 2. Validate the Instance.
> using the delightful Schematron (thanks!)
so far so good.
>
> 3. Adapt the Instance (depending on validation result) into tags for a
> CastorTransformer, which makes/modifies/prods your bean.
The CastorTransformer marshalls a JavaBean into XML document. Currently it
only "prods" but does not "make/modify".
How would you bind the XML data from 2. into JavaBeans in the business
domain?
> 4. Adapt the Instance (depending on Castor result) into whatever your next
> stage needs to be
I assume you mean adapt through XSLT ?
> I do not think we are duplicating effort.
> I think both of these efforts will (at the very least) prove to be useful
> examples for other developers, regardless of the final outcome.
>
> As long as we keep sharing our ideas publicly (as has happened to great
> effect so far!) we have a win-win situation.
>
> I am not convinced that one pattern can solve every problem in this realm
> .... there is still a lot to explore ....
Definitely.
Let's keep it moving and close the subject this time.
It would be sad to see this discussion dead end like the other ones which
tried to tackle the same problem in the last 2 years.
Looking forward to your comments.
Cheers,
Ivelin
>
>
> Thanks for your help so far!
>
>
> regards Jeremy
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
>
> ---------------------------------------------------------------------
> 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: Dynamic Schematron validation works!
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 1:23 pm -0600 16/3/02, Ivelin Ivanov wrote:
>As Torsten suggested, shall we please try to agree on the requirements for
>the problem we're trying to solve.
>Starting with something non-trivial, but not too comlex as well. Just enough
>to demonstrate good potential and allow for further extension.
Hi Ivelin,
Not wanting to be negative or anything ... but we have quite different
approaches driven by different needs, we may or may not be able to
reconcile them.
It does not really matter right now, we will _all_ learn from both attempts
....
What I mean more specifically:
As I understand it .... you re trying to make a generic system (partially
influenced by previous work done attempting to implement the XForms
standard) for building complex business objects.
Furthermore you are trying to make your _sitemap_ adapt itself to the
progress of the transaction.
I on the other hand am trying to make generic patterns for assembling
sitemap and XSLT components, as an example of how to add the ability to
edit your own existing assets, to an existing publishing project.
What's more, I am implementing my logic differently; by having transformers
modify the _content_ of the pipeline to adapt to the progress of the
transaction.
Both techniques are very interesting in their own right!
If I had access to the stuff you are doing now, 12 months ago, I'd be
dancing in the streets! It was JUST what I wanted for the Crudlet project I
was working on, where we had large and complex JavaBeans to fill in and
manipulate, requiring multiple forms to do the job.
If you were to follow my pattern (which I am not suggesting, this is just
an illustration) you would:
1. Generate an Instance
using XSP or RequestGenerator + XSLT etc.
2. Validate the Instance.
using the delightful Schematron (thanks!)
3. Adapt the Instance (depending on validation result) into tags for a
CastorTransformer, which makes/modifies/prods your bean.
4. Adapt the Instance (depending on Castor result) into whatever your next
stage needs to be
.......
I do not think we are duplicating effort.
I think both of these efforts will (at the very least) prove to be useful
examples for other developers, regardless of the final outcome.
As long as we keep sharing our ideas publicly (as has happened to great
effect so far!) we have a win-win situation.
I am not convinced that one pattern can solve every problem in this realm
.... there is still a lot to explore ....
Thanks for your help so far!
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Dynamic Schematron validation works!
Posted by Ivelin Ivanov <iv...@iname.com>.
As Torsten suggested, shall we please try to agree on the requirements for
the problem we're trying to solve.
Starting with something non-trivial, but not too comlex as well. Just enough
to demonstrate good potential and allow for further extension.
Torten, you had an idea about a feedback wizard, which I liked.
Can you please present the requirements to the list, so that we can agree on
it and have a more focused discussion.
Thank you.
Ivelin
----- Original Message -----
From: "Jeremy Quinn" <je...@media.demon.co.uk>
To: <co...@xml.apache.org>
Sent: Saturday, March 16, 2002 10:45 AM
Subject: Re: Dynamic Schematron validation works!
> At 1:57 pm +0100 16/3/02, Torsten Curdt wrote:
> >Jeremy Quinn wrote:
> >
> >> At 11:49 am +0100 16/3/02, Torsten Curdt wrote:
> >>
> >>>Jeremy, I don't want to spoil your enthusiasm but there still two major
> >>>issues... I've been talking with Ivelin off the list about these
issues.
> >>>(Maybe we should move our discussion to the list?!)
> >>>
> >>>1) current binding prohibits the use of checkboxes (good old checkbox
> >>> problem *sigh*) You cannot turn the checkbox off via request.
> >>>
> >>
> >> I am taking a different approach, it should not be a problem in
> >> <slash-edit/>; you have to supply (very simple) StyleSheet snippets to
> >> convert _your_ incoming request data into an instance to be validated.
> >>
> >> This gives you the opportunity to detect a missing field (un-checked
box),
> >> because your StyleSheet should know about it.
> >
> >
> >exactly... that's the trick. but I didn't get your idea about the
> >stylesheet snippets yet though...
>
> <snip/>
>
> it's almost working .... 'im soon come .... lemme finish
>
> hopefully then there will be a concrete example of what I am going on
about ;)
>
> I think you will find our models are different, and I have not solved
every
> problem yet (I am sneaking up on then one by one .... ;)
>
> regards Jeremy
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
>
> ---------------------------------------------------------------------
> 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: Dynamic Schematron validation works!
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 1:57 pm +0100 16/3/02, Torsten Curdt wrote:
>Jeremy Quinn wrote:
>
>> At 11:49 am +0100 16/3/02, Torsten Curdt wrote:
>>
>>>Jeremy, I don't want to spoil your enthusiasm but there still two major
>>>issues... I've been talking with Ivelin off the list about these issues.
>>>(Maybe we should move our discussion to the list?!)
>>>
>>>1) current binding prohibits the use of checkboxes (good old checkbox
>>> problem *sigh*) You cannot turn the checkbox off via request.
>>>
>>
>> I am taking a different approach, it should not be a problem in
>> <slash-edit/>; you have to supply (very simple) StyleSheet snippets to
>> convert _your_ incoming request data into an instance to be validated.
>>
>> This gives you the opportunity to detect a missing field (un-checked box),
>> because your StyleSheet should know about it.
>
>
>exactly... that's the trick. but I didn't get your idea about the
>stylesheet snippets yet though...
<snip/>
it's almost working .... 'im soon come .... lemme finish
hopefully then there will be a concrete example of what I am going on about ;)
I think you will find our models are different, and I have not solved every
problem yet (I am sneaking up on then one by one .... ;)
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Dynamic Schematron validation works!
Posted by Torsten Curdt <tc...@dff.st>.
Jeremy Quinn wrote:
> At 11:49 am +0100 16/3/02, Torsten Curdt wrote:
>
>>Jeremy, I don't want to spoil your enthusiasm but there still two major
>>issues... I've been talking with Ivelin off the list about these issues.
>>(Maybe we should move our discussion to the list?!)
>>
>>1) current binding prohibits the use of checkboxes (good old checkbox
>> problem *sigh*) You cannot turn the checkbox off via request.
>>
>
> I am taking a different approach, it should not be a problem in
> <slash-edit/>; you have to supply (very simple) StyleSheet snippets to
> convert _your_ incoming request data into an instance to be validated.
>
> This gives you the opportunity to detect a missing field (un-checked box),
> because your StyleSheet should know about it.
exactly... that's the trick. but I didn't get your idea about the
stylesheet snippets yet though...
> There are two samples of this happening, one for the StreamGenerator, and
> one for the RequestGenerator, it could easily be done in XSP too, depending
> on your taste.
Where do you mean exactly? *puzzled*
>>2) AFAIU validation happens inside the XSLT transformer. IMHO this should
>> happen inside an action. Otherwise we have to choose what page to show
>> from the XML *content*. Only way I see do this is to create another
>> transformer for this. But still you are not able to react on the
>> validation result inside the sitemap... Or am I missing here something?
>> (Could a transformer set a request attribute that can become available
>> in the sitemap?)
>>
>
> I do not think you can easily send data back to the sitemap, though I am
> not needing to do that .....
now you see me curious....
> The scheme I am working on uses several Transformers and XSLT along the
> pipeline to adapt the XML according to what needs to be done to it.
>
> For instance, after the validation XSLT has run, another XSLT checks for
> generated errors. If there are none, the instance content is wrapped with
> the appropriate <source:write/> and the <validationResult/> is discarded.
> Otherwise, the instance is not wrapped, the <validationResult/> is left,
> but the behaviour is changed to 'get', meaning 'editor2html.xsl' XSLT will
> generate a form from your instance, to show the user again, with errors
> appropriately displayed.
>
> Next in line is the SourceWritingTransformer, there may or may not be a job
> for it to do ..... this is dependant on the tags in the stream. No need for
> conditional sitemap components.
Well, sounds good for a single page form (as well as Ivelin stuff yet)
but as soon as we have mulitple pages I see the sitemap and involved.
<snip/>
>>Currently I am trying to merge Ivelin work what I'm am currently working
>>on. I hope I can present this in a few days to the list...
>>
>
> With any luck I'll get this finished today, you can see what I mean.
I'm currious but still a little skeptic...
I currently already have a proof-of-concept prototype but it's not yet
ready for prime time. I see all this more like this:
let's say we want to have an instance (MODEL):
<userform>
<username>Torsten</username>
<email>tcurdt@apache.org</email>
</userform>
I want this model to be represented in either in XSD, relax-ng or
whatever you like. The store will be an instance implementation like
- DOMInstance
- BeanInstance
then we have views for each page in the wizard / multipage form (VIEW):
page1.xml:
<form>
<textbox ref="userform/username"/>
<button method="next"/>
</form>
page2.xml
<form>
<textbox ref="userform/email"/>
<button method="save"/>
</form>
Now I still see actions as the CONTROLLER of choice. The buttons map to
an action defining what to be saved into the instance. So we also don't
have the checkbox problem. Of course writing such an action should be as
simple as possible. For usual simple forms it should be even possible to
specify everything via a XML descriptor.
That's how I see things...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Dynamic Schematron validation works!
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 11:49 am +0100 16/3/02, Torsten Curdt wrote:
>Jeremy, I don't want to spoil your enthusiasm but there still two major
>issues... I've been talking with Ivelin off the list about these issues.
>(Maybe we should move our discussion to the list?!)
>
>1) current binding prohibits the use of checkboxes (good old checkbox
> problem *sigh*) You cannot turn the checkbox off via request.
I am taking a different approach, it should not be a problem in
<slash-edit/>; you have to supply (very simple) StyleSheet snippets to
convert _your_ incoming request data into an instance to be validated.
This gives you the opportunity to detect a missing field (un-checked box),
because your StyleSheet should know about it.
There are two samples of this happening, one for the StreamGenerator, and
one for the RequestGenerator, it could easily be done in XSP too, depending
on your taste.
>2) AFAIU validation happens inside the XSLT transformer. IMHO this should
> happen inside an action. Otherwise we have to choose what page to show
> from the XML *content*. Only way I see do this is to create another
> transformer for this. But still you are not able to react on the
> validation result inside the sitemap... Or am I missing here something?
> (Could a transformer set a request attribute that can become available
> in the sitemap?)
I do not think you can easily send data back to the sitemap, though I am
not needing to do that .....
The scheme I am working on uses several Transformers and XSLT along the
pipeline to adapt the XML according to what needs to be done to it.
For instance, after the validation XSLT has run, another XSLT checks for
generated errors. If there are none, the instance content is wrapped with
the appropriate <source:write/> and the <validationResult/> is discarded.
Otherwise, the instance is not wrapped, the <validationResult/> is left,
but the behaviour is changed to 'get', meaning 'editor2html.xsl' XSLT will
generate a form from your instance, to show the user again, with errors
appropriately displayed.
Next in line is the SourceWritingTransformer, there may or may not be a job
for it to do ..... this is dependant on the tags in the stream. No need for
conditional sitemap components.
Someone wanting to use <slash-edit/> as the basis for editing their own
project, mainly has to write simple "Adaptor" XSLTs for their own doctype.
Internal 'put' pipeline
request data -> validateable editor/instance
validated editor/instance -> writeable editor/instance
(or not, if not validated)
written editor/instance -> main pipeline
Main Pipeline (aggregates above with the config file)
editor/instance -> html, depending on 'behaviour'
ie. 'get' & 'new' make the editor/instance into a form
'see' makes it into a simple editor view
'put' displays result of successful save
'dir' shows a directory listing
>Currently I am trying to merge Ivelin work what I'm am currently working
>on. I hope I can present this in a few days to the list...
With any luck I'll get this finished today, you can see what I mean.
If this helps, here are my notes (for the internal pipelines) for how it
behaves:
(where <page/> represents arbitrarily complex XML)
<map:match pattern="fetch-put(alpha,**)">
<map:act type="request">
<map:parameter name="parameters" value="true"/>
<map:generate type="stream">
<map:parameter name="form-name" value="xml-field"/>
</map:generate>
<map:transform src="editor/stylesheets/stream2editor.xsl">
<map:parameter name="sub" value="alpha"/>
<map:parameter name="target" value="{target}"/>
</map:transform>
<map:transform src="cocoon:/make-validator(page)"/>
<map:transform src="editor/stylesheets/editor2writer.xsl">
<map:parameter name="base" value="docs"/>
</map:transform>
<map:transform type="sourcewriter"/>
<map:serialize type="xml"/>
</map:act>
</map:match>
<map:match pattern="*-validator">
<map:generate src="editor/docs/schematron-{1}-validator.xml"/>
<map:transform src="editor/stylesheets/schematron-validator2xsl.xsl"/>
<map:serialize type="xml"/>
</map:match>
stream2editor.xsl outputs:
<editor sub="alpha">
<instance behaviour="put" target="/blah.xml">
<page/>
</instance>
</editor>
cocoon:page-validator outputs:
<editor sub="alpha">
<instance behaviour="put" target="/blah.xml">
<page/>
</instance>
<validationReport/>
</editor>
editor2writer.xsl outputs:
<editor sub="alpha">
<instance behaviour="put" target="/blah.xml">
<source:write src="base/blah.xml">
<page/>
</source:write>
</instance>
</editor>
or this on validation error (the behaviour change means you get it back as
a form):
<editor sub="alpha">
<instance behaviour="get" target="/blah.xml">
<page/>
</instance>
<validationReport/>
</editor>
Hope this helps
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Dynamic Schematron validation works!
Posted by Ivelin Ivanov <iv...@iname.com>.
----- Original Message -----
From: "Torsten Curdt" <tc...@dff.st>
To: <co...@xml.apache.org>; "Ivelin Ivanov" <iv...@sbcglobal.net>
Sent: Sunday, March 17, 2002 9:11 AM
Subject: Re: Dynamic Schematron validation works!
> > > 2) AFAIU validation happens inside the XSLT transformer. IMHO this
should
> > > happen inside an action. Otherwise we have to choose what page to
show
> > > from the XML *content*. Only way I see do this is to create another
> > > transformer for this. But still you are not able to react on the
> > > validation result inside the sitemap... Or am I missing here
something?
> > > (Could a transformer set a request attribute that can become
available
> > > in the sitemap?)
> >
> > I've come up with 2 possible solutions to this problem so far.
> > (It seems that you came to the same yourself. )
> >
> > 1) I think we can do a specialized "Validation" transformer, which
extends
> > from XSLT transformer, but also sticks in the sitemap a
"validationResult"
> > attribute, which a subsequent selector can use. The idea seems feasible
> > based on the behaviour of the WritingDomTransformer which sticks in the
> > sitemap a DOM object representing the SAX stream.
>
> this is the only way I see for this approach. but Ivelin: isn't there a
> way of using schematron more in a java way? as long as you want schematron
> only to display some errors fine. But ussually I check my business
> objects again before I save them inside an action. Something like:
>
> save-action() {
> if (bo comforms to XSD) {
> save to whatever
> }
> else {
> error: bo does not conform to XSD
> }
> }
>
> How would you do this with schematron inside an action. I'd be glad if we
> could find a way to do this with schemtron, too.
Before I answer, I'd make a note that I am not aware of a XSD validator
which can go directly against a JavaBean.
So I assume that this line
> if (bo comforms to XSD) {
actuall assumes an implicit transition from BO to XMLSource to XSD
validation.
If we want to stick to the XSLT implementation of Schematron, then
XMLSource myBOasXML = Castor.marshall (bo) ;
save-action() {
// XSD validation
if (myBOasXML comforms to XSD) {
// Schematron validation
XMLSource schemtraonResultAsXML = XSLT.process( myBO,
mySchematronStylesheet )
CastorOrJAXB.unmarshall ( schemtraonResultAsXML,
schematronResultJavaBean );
if ( schematronResultJavaBean.errors > 0 )
{
DING, ERROR, display errors and diagnostics
}
else
save to whatever
}
else {
error: bo does not conform to XSD
}
}
Maybe it's preferable though to use the Java implementation of Schematron:
http://www.informatik.hu-berlin.de/~obecker/SchematronAPI/
It works fine against DOM. It shouldn't be too hard to extend it to work
directly with BOs by replacing the XPath calls to a DOM with JXPath calls to
the BO.
>
> > 2) How about a XPath selector, whose when attribute will be a valid
XPath
> > test expression executed against the SAX stream?
> > then you can possible do something like:
> >
> > <transformer src="validating-schematron-report.xsl">
> > <selector type="xpath">
> > <selector when="/validatingResult/pattern">
> > ... go back to the same page
> > <selector otherwise>
> > ... move on with life
> >
> >
> > So which one of the two (if any) is better ?
>
> AFAIK this is not possible without creating a DOM.... we have had a
> discussion on this topic lately...
What if we implement only the subset of XPath which satisfies 90% of the
needs and can work with a SAX stream.
Many times the test would be like:
1) Does element A exist, or
2) Does element A have value b, or
3) Does element A appear n times, or
4) similar tests against attributes
All of the above can work with SAX stream without the need to remember the
whole document.
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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: Dynamic Schematron validation works!
Posted by Ivelin Ivanov <iv...@iname.com>.
Torten,
can you email me your Relax-NG validator, so that I can start working on the
Schematron validator.
Cheers,
Ivelin
----- Original Message -----
From: "Torsten Curdt" <tc...@dff.st>
To: <co...@xml.apache.org>; "Ivelin Ivanov" <iv...@sbcglobal.net>
Sent: Sunday, March 17, 2002 9:11 AM
Subject: Re: Dynamic Schematron validation works!
> > > 2) AFAIU validation happens inside the XSLT transformer. IMHO this
should
> > > happen inside an action. Otherwise we have to choose what page to
show
> > > from the XML *content*. Only way I see do this is to create another
> > > transformer for this. But still you are not able to react on the
> > > validation result inside the sitemap... Or am I missing here
something?
> > > (Could a transformer set a request attribute that can become
available
> > > in the sitemap?)
> >
> > I've come up with 2 possible solutions to this problem so far.
> > (It seems that you came to the same yourself. )
> >
> > 1) I think we can do a specialized "Validation" transformer, which
extends
> > from XSLT transformer, but also sticks in the sitemap a
"validationResult"
> > attribute, which a subsequent selector can use. The idea seems feasible
> > based on the behaviour of the WritingDomTransformer which sticks in the
> > sitemap a DOM object representing the SAX stream.
>
> this is the only way I see for this approach. but Ivelin: isn't there a
> way of using schematron more in a java way? as long as you want schematron
> only to display some errors fine. But ussually I check my business
> objects again before I save them inside an action. Something like:
>
> save-action() {
> if (bo comforms to XSD) {
> save to whatever
> }
> else {
> error: bo does not conform to XSD
> }
> }
>
> How would you do this with schematron inside an action. I'd be glad if we
> could find a way to do this with schemtron, too.
>
> > 2) How about a XPath selector, whose when attribute will be a valid
XPath
> > test expression executed against the SAX stream?
> > then you can possible do something like:
> >
> > <transformer src="validating-schematron-report.xsl">
> > <selector type="xpath">
> > <selector when="/validatingResult/pattern">
> > ... go back to the same page
> > <selector otherwise>
> > ... move on with life
> >
> >
> > So which one of the two (if any) is better ?
>
> AFAIK this is not possible without creating a DOM.... we have had a
> discussion on this topic lately...
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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: Dynamic Schematron validation works!
Posted by Torsten Curdt <tc...@dff.st>.
> > 2) AFAIU validation happens inside the XSLT transformer. IMHO this should
> > happen inside an action. Otherwise we have to choose what page to show
> > from the XML *content*. Only way I see do this is to create another
> > transformer for this. But still you are not able to react on the
> > validation result inside the sitemap... Or am I missing here something?
> > (Could a transformer set a request attribute that can become available
> > in the sitemap?)
>
> I've come up with 2 possible solutions to this problem so far.
> (It seems that you came to the same yourself. )
>
> 1) I think we can do a specialized "Validation" transformer, which extends
> from XSLT transformer, but also sticks in the sitemap a "validationResult"
> attribute, which a subsequent selector can use. The idea seems feasible
> based on the behaviour of the WritingDomTransformer which sticks in the
> sitemap a DOM object representing the SAX stream.
this is the only way I see for this approach. but Ivelin: isn't there a
way of using schematron more in a java way? as long as you want schematron
only to display some errors fine. But ussually I check my business
objects again before I save them inside an action. Something like:
save-action() {
if (bo comforms to XSD) {
save to whatever
}
else {
error: bo does not conform to XSD
}
}
How would you do this with schematron inside an action. I'd be glad if we
could find a way to do this with schemtron, too.
> 2) How about a XPath selector, whose when attribute will be a valid XPath
> test expression executed against the SAX stream?
> then you can possible do something like:
>
> <transformer src="validating-schematron-report.xsl">
> <selector type="xpath">
> <selector when="/validatingResult/pattern">
> ... go back to the same page
> <selector otherwise>
> ... move on with life
>
>
> So which one of the two (if any) is better ?
AFAIK this is not possible without creating a DOM.... we have had a
discussion on this topic lately...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Dynamic Schematron validation works!
Posted by Ivelin Ivanov <iv...@iname.com>.
----- Original Message -----
From: "Torsten Curdt" <tc...@dff.st>
To: "Cocoon Dev" <co...@xml.apache.org>
Sent: Saturday, March 16, 2002 4:49 AM
Subject: Re: Dynamic Schematron validation works!
>
> Jeremy, I don't want to spoil your enthusiasm but there still two major
> issues... I've been talking with Ivelin off the list about these issues.
> (Maybe we should move our discussion to the list?!)
>
> 1) current binding prohibits the use of checkboxes (good old checkbox
> problem *sigh*) You cannot turn the checkbox off via request.
Does my proposed solution work ?
>
> 2) AFAIU validation happens inside the XSLT transformer. IMHO this should
> happen inside an action. Otherwise we have to choose what page to show
> from the XML *content*. Only way I see do this is to create another
> transformer for this. But still you are not able to react on the
> validation result inside the sitemap... Or am I missing here something?
> (Could a transformer set a request attribute that can become available
> in the sitemap?)
I've come up with 2 possible solutions to this problem so far.
(It seems that you came to the same yourself. )
1) I think we can do a specialized "Validation" transformer, which extends
from XSLT transformer, but also sticks in the sitemap a "validationResult"
attribute, which a subsequent selector can use. The idea seems feasible
based on the behaviour of the WritingDomTransformer which sticks in the
sitemap a DOM object representing the SAX stream.
2) How about a XPath selector, whose when attribute will be a valid XPath
test expression executed against the SAX stream?
then you can possible do something like:
<transformer src="validating-schematron-report.xsl">
<selector type="xpath">
<selector when="/validatingResult/pattern">
... go back to the same page
<selector otherwise>
... move on with life
So which one of the two (if any) is better ?
>
> Currently I am trying to merge Ivelin work what I'm am currently working
> on. I hope I can present this in a few days to the list...
> --
> Torsten
>
> > Dear All,
> >
> > Encouraged by Ivelin Ivanov's work, I tried to see if the XSLT generated
by
> > Schematron could be dynamically generated.
> >
> > It can!
> >
> > Here were my test pipelines (using all Ivelin's files):
> >
> >
> > Using a pre-made validating XSLT:
> >
> > <map:match pattern="static-validation">
> > <map:generate src="schematron/some-xmlform.xml"/>
> > <map:transform src="schematron/xmlform-sch-report.xsl"/>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> > Using a validating XSLT, generated by another pipeline:
> >
> > <map:match pattern="dynamic-validation">
> > <map:generate src="schematron/some-xmlform.xml"/>
> > <map:transform src="cocoon:/make-validator"/>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> > A pipeline for generating validating XSLT:
> >
> > <map:match pattern="make-validator">
> > <map:generate src="schematron/xmlform-sch-report.xml"/>
> > <map:transform src="schematron/xmlform-schematron.xsl"/>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> >
> > Apart from having to comment out a reference to <saxon:output/> in
> > 'wrappers.xsl' it all worked fine.
> >
> > I viewed this with MSIE 5, the xml was the same as the samples.
> >
> >
> > Cool!
>
>
> ---------------------------------------------------------------------
> 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: Dynamic Schematron validation works!
Posted by Torsten Curdt <tc...@dff.st>.
Jeremy, I don't want to spoil your enthusiasm but there still two major
issues... I've been talking with Ivelin off the list about these issues.
(Maybe we should move our discussion to the list?!)
1) current binding prohibits the use of checkboxes (good old checkbox
problem *sigh*) You cannot turn the checkbox off via request.
2) AFAIU validation happens inside the XSLT transformer. IMHO this should
happen inside an action. Otherwise we have to choose what page to show
from the XML *content*. Only way I see do this is to create another
transformer for this. But still you are not able to react on the
validation result inside the sitemap... Or am I missing here something?
(Could a transformer set a request attribute that can become available
in the sitemap?)
Currently I am trying to merge Ivelin work what I'm am currently working
on. I hope I can present this in a few days to the list...
--
Torsten
> Dear All,
>
> Encouraged by Ivelin Ivanov's work, I tried to see if the XSLT generated by
> Schematron could be dynamically generated.
>
> It can!
>
> Here were my test pipelines (using all Ivelin's files):
>
>
> Using a pre-made validating XSLT:
>
> <map:match pattern="static-validation">
> <map:generate src="schematron/some-xmlform.xml"/>
> <map:transform src="schematron/xmlform-sch-report.xsl"/>
> <map:serialize type="xml"/>
> </map:match>
>
> Using a validating XSLT, generated by another pipeline:
>
> <map:match pattern="dynamic-validation">
> <map:generate src="schematron/some-xmlform.xml"/>
> <map:transform src="cocoon:/make-validator"/>
> <map:serialize type="xml"/>
> </map:match>
>
> A pipeline for generating validating XSLT:
>
> <map:match pattern="make-validator">
> <map:generate src="schematron/xmlform-sch-report.xml"/>
> <map:transform src="schematron/xmlform-schematron.xsl"/>
> <map:serialize type="xml"/>
> </map:match>
>
>
> Apart from having to comment out a reference to <saxon:output/> in
> 'wrappers.xsl' it all worked fine.
>
> I viewed this with MSIE 5, the xml was the same as the samples.
>
>
> Cool!
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org