You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ivelin Ivanov <iv...@apache.org> on 2002/06/11 15:29:41 UTC
Re: New Xinclude Implementation (was: [VOTE] Schematron validator
in Anteater (and Cocoonvalidating Transformer))
Michael suggests a new XInclude implementation.
Since we're talking about merging CInclude and XInclude, is someone
interested to have Michael's code?
I guess Michael should submits a patch in Bugzilla with the code, so
whoever is interested can pick it up from there.
Ivelin
Michael Wechner wrote:
>
>
> Ivelin Ivanov wrote:
>
>> Although on the other hand, it will be nice to use XInclude instead of
>> entities,
>> provided that there is a good implementation in Cocoon.
>
>
>
>
> Concerning a Cocoon XInlcude implementation:
> I have migrated my own XInclude-Processor onto Cocoon,
> because the existing one missed some features I needed, e.g.:
> -Loop detection
> -Exception handling: FileNotFound, Timeout, NotWellformed, ...
> -Caching
> -Resolving arbitrary depth
>
> and I didn't have time to modify the existing one, which is shipped
> with Cocoon.
>
> The problem is that I wrote it about two years ago and it would
> need some refactoring (it's DOM based, which means I extended the
> AbstractDOMTransformer). On the other hand it's very stable and
> real-world proven. I am currently using it for Wyona and it works
> very fine so far.
>
> In case you are interested I can send you the code or just download
> the newest version of Wyona (http://www.wyona.org).
>
> All the best
>
> Michael
>
>
>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: "Ivelin Ivanov" <iv...@apache.org>
>> To: "Ivelin Ivanov" <iv...@apache.org>; "Ovidiu Predescu"
>> <ov...@apache.org>; <af...@lists.sourceforge.net>;
>> <co...@xml.apache.org>
>> Sent: Saturday, June 08, 2002 8:08 PM
>> Subject: Re: [VOTE] Schematron validator in Anteater (and
>> Cocoonvalidating
>> Transformer)
>>
>>
>>
>>> Ovidiu,
>>>
>>> I think I have answered my question about step composition.
>>> Since Anteater is an Ant extenstion, the method used by WebTest (and
>>>
>> Latka)
>>
>>> is applicable here.
>>>
>>> We can just use external XML Entities to reference test steps.
>>> Although not the most elegant mechanism, it is simple and works.
>>>
>>> See here for example:
>>> http://webtest.canoo.com/webtest/samples/ffo/NatPerSingle/MostSimple.xml
>>>
>>>
>>> I am still waiting for response on the validation syntax and JUnit
>>> report
>>> feed.
>>>
>>>
>>>
>>> Ivelin
>>>
>>>
>>> ----- Original Message -----
>>> From: "Ivelin Ivanov" <iv...@apache.org>
>>> To: "Ovidiu Predescu" <ov...@apache.org>;
>>> <af...@lists.sourceforge.net>; <co...@xml.apache.org>
>>> Sent: Friday, June 07, 2002 11:48 PM
>>> Subject: Re: [VOTE] Schematron validator in Anteater (and
>>> Cocoonvalidating
>>> Transformer)
>>>
>>>
>>>
>>>> I will be interested to contribute some code.
>>>> The validator package is totally independent of Avalon.
>>>> It only needs commons-jxpath.jar
>>>>
>>>> The package is org.apache.cocoon.components.validation
>>>>
>>>> I guess I can just zip up the files in the package for anteater.
>>>>
>>>> I would like us to work out the exact syntax before starting, though.
>>>>
>>>> How do we plan to generate junit reports.
>>>> Right now I don't see a nice way to interrupt a test, if there was a
>>>> validation error, and jump straight to the junit reporting.
>>>>
>>>> I have also asked a question about reusing steps among test cases.
>>>> How do you suggest this can be done?
>>>>
>>>> Once we work out the architectural problems, I'll move to coding.
>>>>
>>>> My sf.net login is "ivelin"
>>>>
>>>>
>>>>
>>>>
>>>> Ivelin
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Ovidiu Predescu" <ov...@apache.org>
>>>> To: "Ivelin Ivanov" <iv...@apache.org>;
>>>>
>>> <af...@lists.sourceforge.net>;
>>>
>>>> <co...@xml.apache.org>
>>>> Sent: Friday, June 07, 2002 10:18 PM
>>>> Subject: Re: [VOTE] Schematron validator in Anteater (and
>>>>
>> Cocoonvalidating
>>
>>>> Transformer)
>>>>
>>>>
>>>>
>>>>> Ivelin,
>>>>>
>>>>> This sounds very interesting, are you interested in adding this
>>>>>
>> feature
>>
>>> to
>>>
>>>>> Anteater and writing some documentation for it? If you're interested,
>>>>>
>> I
>>
>>>> can
>>>>
>>>>> make you a committer to the project, so you can develop more easily.
>>>>>
>>> Just
>>>
>>>>> let me know your SourceForge account.
>>>>>
>>>>> The way I'd see this added is through an additional package in CVS. As
>>>>>
>>> I'm
>>>
>>>>> not familiar with the internals of the validator, I can't comment much
>>>>>
>>> on
>>>
>>>>> how this can be integrated. Is the validator implemented as a
>>>>>
>> component
>>
>>>>> using Avalon? If so you'd need to change it to match the Ant style of
>>>>> writing extensions. If exactly the same code from Cocoon can be reused
>>>>> unmodified in Anteater, then perhaps the best option is to build a jar
>>>>>
>>>> file
>>>>
>>>>> in Cocoon, and just drop it in Anteater's lib/ directory.
>>>>>
>>>>> Cheers,
>>>>> Ovidiu
>>>>>
>>>>> On 6/7/02 4:51 PM, "Ivelin Ivanov" <iv...@apache.org> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> =================================
>>>>>> || VERY LONG !!! ||
>>>>>> =================================
>>>>>> || AND INTERESTING. ||
>>>>>> =================================
>>>>>>
>>>>>>
>>>>>> I am surprised that there is not much interest in the Cocoon
>>>>>>
>> community
>>
>>>> for
>>>>
>>>>>> Anteater. What do people use for web apps functional test suites?
>>>>>> There are a few other open source test tools, but I think Anteater
>>>>>>
>> has
>>
>>>> great
>>>>
>>>>>> potential. Especially for Cocoon apps.
>>>>>>
>>>>>> So, let's begin:
>>>>>>
>>>>>>
>>>>>>
>>>>>> - 1 -
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> While Anteater is still not solidified and has a relatively small
>>>>>>
>> user
>>
>>>> base,
>>>>
>>>>>> I would like to suggest an architectural change, which is compatible
>>>>>>
>>>> with
>>>>
>>>>>> Anteater's values, but will hopefully
>>>>>> improve it in the following areas:
>>>>>>
>>>>>> 1) standartization
>>>>>> 2) learning curve
>>>>>> 3) cross project code reuse
>>>>>> 4) maintainance
>>>>>>
>>>>>> The ideas is to use references to schema documents of standard XML
>>>>>>
>>>> languages
>>>>
>>>>>> (like Schematron, DTD, XML Schema, Relax NG) for response
>>>>>>
>> validation,
>>
>>>>>> instead of supporting a proprietary grammar.
>>>>>> I suggest that we use the org.apache.cocoon.components.validation
>>>>>>
>>>> package
>>>>
>>>>>> which is an independent component in Cocoon's main tree and is used
>>>>>>
>> by
>>
>>>>>> XMLForm.
>>>>>> The Schematron implementation is already available and I think it is
>>>>>>
>>>> quite
>>>>
>>>>>> suitable for Anteater, because Schematron is a superset of
>>>>>>
>> Anteater's
>>
>>>> match
>>>>
>>>>>> element.
>>>>>> To be precise it is a superset of the validating use, i.e the cases
>>>>>>
>>> when
>>>
>>>>>> match is used to assign value to a "result" property. Asigning
>>>>>>
>> values
>>
>>>> within
>>>>
>>>>>> <match/> to other properties which are used for subsequent requests
>>>>>>
>> is
>>
>>> a
>>>
>>>>>> separate concern.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> - 2 -
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Schematron was specificly designed for partial, multi-phase
>>>>>>
>> validation
>>
>>>> and
>>>>
>>>>>> user friendly error reporting.
>>>>>>
>>>>>> I'll explain how points 1-4 above are addressed by this proposal:
>>>>>>
>>>>>> 1) Schematron is relatively popular. There are a number of articles
>>>>>>
>> in
>>
>>>>>> popular magazines which promote Schematron over other validating
>>>>>>
>>>> schemas.
>>>>
>>>>>> 2) Schematron is very easy to learn. Specification and tutorials are
>>>>>> availbel. There is also supporing discussion groups with decent
>>>>>>
>>> response
>>>
>>>>>> time.
>>>>>> 3) Schematron is used for a number of projects. For example there is
>>>>>>
>> a
>>
>>>>>> complete RSS 1.0 validating schema available on the RSS site.
>>>>>> http://home.freeuk.com/leigh.dodds/rss_validator/
>>>>>> XMLForm is using schematron extensively as well. Slash-edit is
>>>>>>
>> another
>>
>>>>>> example.
>>>>>> 4) Maintainance of Schematron documents is easy. Minor local changes
>>>>>>
>>> are
>>>
>>>>>> made as the underlying (validated) model changes.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> - 3 -
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 5) Bonus ;)
>>>>>>
>>>>>> Here is one additional reason why I posted this proposal.
>>>>>> Validating Schematron documents can be referenced in a transparent
>>>>>> transformer prior to a page serialization.
>>>>>> This can be useful in development and QA, to catch and report bugs
>>>>>>
>> in
>>
>>>>>> content (HTML, WAP, XML, etc.) during navigation.
>>>>>>
>>>>>> Searching for problems in a broken HTML page (or other xml markup)
>>>>>>
>> can
>>
>>>> be
>>>>
>>>>>> painful.
>>>>>> Instead of searching for the missing tags or label or icon, the
>>>>>>
>> tester
>>
>>>> (or
>>>>
>>>>>> developer) will see a meaningful error report in place of the actual
>>>>>>
>>>> page.
>>>>
>>>>>> After testing certain pages time and again, the eye tends to ignore
>>>>>>
>>>> elements
>>>>
>>>>>> peripheral to the currently tested feature.
>>>>>> If there is an underlying validating document which is applied
>>>>>>
>> before
>>
>>>>>> display, then things may be easier. The developer (tester) has to
>>>>>>
>> only
>>
>>>> make
>>>>
>>>>>> changes to it when the page structure changes.
>>>>>> The rest of the time this document will be a safeguard of unexpected
>>>>>> problems caused as side efects by the development of other features
>>>>>>
>> or
>>
>>>> bug
>>>>
>>>>>> fixes or another one of the infinite other possible reasons.
>>>>>> The transformer applying the validating document can be, of course,
>>>>>>
>>>> turned
>>>>
>>>>>> off in production.
>>>>>>
>>>>>> Now the next interesting part. The forementioned validating
>>>>>>
>> documents
>>
>>>> can be
>>>>
>>>>>> referenced just as well by Anteater regression suites as they can by
>>>>>>
>> a
>>
>>>>>> pipeline embedded validating transformer.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> - 4 -
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> As a quick thought, this is how an Anteater script may look:
>>>>>>
>>>>>> <?xml version="1.0" encoding="utf-8"?>
>>>>>>
>>>>>> <project name="calc-test" default="calc">
>>>>>>
>>>>>> <!-- Simulate the behavior of a user that opens a browser, starts
>>>>>> the calculator example, and goes back in the processing several
>>>>>> times. -->
>>>>>> <target name="calc">
>>>>>> <property name="calc"
>>>>>>
>>> value="${cocoon}/samples/flow/examples/calc/"/>
>>>
>>>>>> <property name="schema-doc-ns"
>>>>>> value="http://www.ascc.net/xml/schematron"/>
>>>>>> <property name="schema-doc-url"
>>>>>> value="${cocoon}/samples/flow/examples/calc/sch-report.xml"/>
>>>>>> <http description="Test the 'calc' JavaScript implementation">
>>>>>> <httpRequest href="${calc}/">
>>>>>> <match>
>>>>>> <xpath select="html/body//form/@action" assign="cont1"/>
>>>>>> <validate phase="page1" assign="violations">
>>>>>> </match>
>>>>>> </httpRequest>
>>>>>>
>>>>>> <echo>result = ${violations}</echo>
>>>>>> </http>
>>>>>>
>>>>>> ....
>>>>>>
>>>>>> Then the Schematron document would be something like:
>>>>>>
>>>>>> <schema xmlns="http://www.ascc.net/xml/schematron">
>>>>>>
>>>>>> <title>Schema for the Calc example</title>
>>>>>>
>>>>>> <phase id="page1">
>>>>>> <p>first page check.</p>
>>>>>> <active pattern="form-present"/>
>>>>>> </phase>
>>>>>> ... other phases ...
>>>>>> <pattern name="Test for HTML form element" id="form-present">
>>>>>> <rule context="/">
>>>>>> <assert test="//form">
>>>>>> Form element expected on this page.
>>>>>> </assert>
>>>>>> <assert test="//form/@action">
>>>>>> Form element must have action attribute.
>>>>>> </assert>
>>>>>> </rule>
>>>>>> ... other rules ...
>>>>>> </pattern>
>>>>>> ... other patterns...
>>>>>>
>>>>>> </schema>
>>>>>> ...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Where the validate element will use the validation package to apply
>>>>>>
>>> the
>>>
>>>>>> schema against the document.
>>>>>> The violations can be then nicely integrated in the JUnit reporting
>>>>>>
>>>> package.
>>>>
>>>>>>
>>>>>>
>>>>>> If there are enough votes I'll contribute some of the work myself.
>>>>>> Help would be certainly appreciated.
>>>>>>
>>>>>>
>>>>>> Thanks for reading this far.
>>>>>>
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>> -= Ivelin =-
>>>>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org