[RT] Cocoon Blocks and internal web services

[Stefano Mazzocchi <st...@apache.org>]

Now that Cocoon 2.0.2 is out of the door, I think it's time that we
continue the discussion on Cocoon Blocks, which, IMO, represent the
major step forward that we should aim for Cocoon 2.1.

Thanks to all of those who helped me shaping up the cocoon block idea.

                                    -- o --

A Cocoon block is a zip archive, with extension .cob and MIME-type to be
defined.

Each Cocoon Block *MUST* implement a behavioral cocoon block "contract"
that describes its behavior. This allows blocks to behave
polymorphically.

This contract is fully identified by a URI.

For validation purposes, the idenfitying URI can also be seen as an
address that locates the 'contract descriptor' that can be used by block
handlers to validate the blocks.

This contract explicitly indicates:

 1) web resources exposed by the block (for example files accessible
from other blocks)
 2) service components exposed by the block (for example avalon
components or sitemap components)

Each block contains a descriptor file (located in
/BLOCK-INF/block.xinfo) which indicates:

 1) information about the block (author, version, original location,
license and all that other block metadata)

 2) behavioral contract that the block implements (along with
information on mappings between the contract and this block's
implementation)

 3) dependencies: this is a list of zero or more 'block contracts' upon
which the block depends.

                                    -- o --

The resources exposed by blocks are accessed using a URI-compatible
protocol description of the form:

 block:[role]://path/resource

where

 block: -> identifies the protocol
 [role] -> identifies the block in the current context and it's a short
identifier that maps to the fully-qualifying URI that identifies the
block contract.

For example, suppose we have something like this:

 <map:transform src="block:skin://xslt/document2html.xslt">

the block role 'skin' must be translated to a fully qualifying URI (much
similar to the prefix -> URI translation that happens for XML
namespaces).

This is done by adding the following semantics to the sitemap:

 <map:blocks>
  <map:block role="skin"
uri="http://apache.org/cocoon/blocks/skin/2.1"/>
 </map:blocks>

After this translation is performed, the 'block:' protocol handler will
have to identifiy the resource and retrieve it from the block archive
(which can be extracted or left compressed, this should not change
behavior since the blocks are not allowed to write in their own
addressing space directly).

This mapping is performed by the block deployer, which has the
information on how to map this URI to the block that was installed to
operate that contract for the requesting block.

This futher decoupling is the key to the polymorphic behavior of blocks:
in fact, the block "role" identifies a contract, not an actual
implementation and it's therefore entirely possible to:

 a) have different implementations of the same block associated to
different blocks, so, for example, two different blocks might require a
'skin' role, but each of them might have associated different
implementations of that role.

 b) share the same implementation between different blocks.

 c) hot-deploy/hot-update a block implementation simply by changing the
last mapping translation.

                                    -- o --

The logic components exposed by the blocks are located exactly as
before, using fully qualified dot-notation for java classes. All
translation and mapping will be automatically performed by the
classloaders.

So, for example, if Block A does

 <map:generator type="mygen" class="com.mystuff.whatever.Generator"/>

the classloader responsible for Block A will look for that class in the
/BLOCK-INF/lib or /BLOCK-INF/classes directories and included jar
archives of the blocks on which this Block A depends on.

                                    -- o --

Here I describe a potential use of a block-based cocoon system:

 1) let us suppose that Cocoon is already installed in a servlet
container and up and running.

 2) let us suppose that we have a tool that implements block
management/deployment on top of Cocoon [how this is implemented is not
important for our current needs]

 3) the user has three ways to install new blocks: 

    - provide the block manager with a URI where the block archive is
located on the web

    - have the block manager discover and locate a block repository,
which will be a web service that will interact with the block manager
and list information on new blocks and all that (sort of apt-get)
 
    - provide the block manager with a 'block deployment descriptor'
which contains an 'installable' and complete dependency set of blocks
that implement a given web application. (this is to ease installation)

 4) once the user has choosen what block/s to install, the block manager
downloads it/them from the internet and reads its metadata to find out
eventual dependencies.

 5) for each dependency, the block manager scans the registry of
currently installed blocks in the system. If a block that implements the
dependent contract is already installed, the user is ask to confirm its
use, otherwise, the block manager will look in the block repositories to
download the appropriate block and will ask the user to choose between a
list of compatible implementations of that role.

In case of deployment descriptors, the block manager can be asked to
install the system without performing checkings (but these are
implementation details)

 6) after all blocks are downloaded and all dependencies are satisfied,
each block that exposes direct URI mounts to the Cocoon public URI space
will have to be *mounted* on that URI space. The user will be asked to
provide these mount points (the blocks will provide default values).
After the mount points are given, the system will check for consistency
of the URI space (one block cannot mount inside the URI space of another
block, for safety reasons) and ask for alternatives if errors are found.

 7) when everything is satisfied, the blocks are deployed and initiated
and they can start providing their own services to both the public URI
space and both internally for the other blocks.

                                    -- o --

So far so good.

There is still one big design issues to address: how detailed is the
block contract and its description.

There can be two different types of component models: strong-typed and
weak-typed. (actually, there are full range between these opposite
points, but anyway)

Java is a language that forces strong-typing and we all came to love
that, but it is also evident that sometimes Java isn't that strong-typed
anymore: it could be possile to have an Avalon component that exposes
the following interface

 interface WeakTyped {
    Object doSomething(Object o) throws Exception;
 }

which is strongly typed from a compiler point of view, but is totally
weak from a behavioral validation point of view.

So, what level of description we need for our block contracts?

I see several levels:

1) no description: blocks identify their contract with an URI that
that's it, there is no way to validate the fact that a block implements
a specified contract, this is the weakest form of contract. It's easier
to implement and places the burden of validation at runtime.

2) little description: the contract identifier indicates the 'skeleton'
of the contract but doesn't declare more detailed behavior. There is a
way to perform structure validation on the blocks and also a way to
auto-document the block contract itself, but the behavioral validation
cannot be automated and it's left to the user checking at runtime.

3) detailed description: the contract identifier indicates both the
skeleton and the behavior of the contract. This allows high granular
automatic validation.

Following these descriptions, the third option seems the best, but let
me warn you: describing the behavior of a block will be an extremely
complex task and could end up being even more complex than describing
web services.

For example, suppose that a block exposes the resource

 block:news://newsfeed

how do we describe it's behavior?

We could start saying that it implements the GET and POST actions, that
the GET action will return a specific schema (that must be included in
the description) and that the POST action requires an XML as payload
that is validated againt another schema.

But this is not enough: behavioral description *depends* on the type of
the exposed resource.

For example, a resource such as 

 block:skin://xslt/document2html

will have to expose the returning MIME-type (XSLT in this case) as well
as it's schema, as well as the schema of the conten that it's capable of
transforming and the schema of the content that is capable of generating
after the transformation.

This can go on forever.

I personally don't think that this level of description is required, but
keeping the contract weak might inhibit the ability for this system to
scale beyond the control of a single development community, since all
block instances will have to be manually validated against a particular
behavior.

Also it is true that it's not up to the block implementors to describe
the block contract, just like it's not up to the API implementor to
describe the API and we all know that writing a contract is a very
expensive and complex task, but luckily it doesn't have to be performed
once per block implementation but only once per block 'contract'.

At the same time, this description format is very well going to be so
complex that WSDL will look like piece of cake and I'm scared about
this.... on the other hand, it might enable things like form validation
and so on automatic and rather painless.

So, anyway, these were the last RT on the topic, now it's your turn to
throw the stones in the lake.

Ciao.


-- 
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: [RT] Cocoon Blocks and internal web services

[Mircea Toma <mi...@apache.org>]

> Yes and no.
>
> The intent is to use the same patterns that inspired the creation of
> Phoenix (which are included in the original Avalon design that Pier,
> Federico and I invented), but *not* to clone Phoenix!
>
> This is because the 'service' concept that can be provided by a
> collection of logic components is very different from the 'internal web
> service' concept that a cocoon block should provide.

Oh, I see what you're saying.

> This different perspective, in fact, suggests different factorization of
> blocks from the ones you outlined above, which are, in fact,
> logic-oriented instead of 'concern-oriented'.
>
> Implementation-wise, I'm pretty sure we might end up "using" parts of
> Phoenix directly (or patch it to make it abstract enough to handle our
> needs as well), but at a totally different level (app-level rather than
> core-level) and driven by different needs and concerns.

I'm not saying that Phoenix blocks should be used to implement "Cocoon 
services", they are not meant for that. Cocoon could use Phoenix very much 
how James uses it (mailets), or if an app. server would be build using 
Phoenix (ejb deployment). Building on top of Phoenix doesn't mean that Cocoon 
cannot have it's own packaging scheme, I think it should because it addresses 
different concerns (web related).

.....
> In case you don't want the installer to go around shopping for this,

This is an example of what a Phoenix service could do for Cocoon. Going 
around and shop for blocks is not a web related service but a deployment 
service thus easily implemented using a Phoenix block.
Things like: XML database, search engine, object store, servlet&JSP engines, 
or Cocoon container are well suited to be implemented as Phoenix blocks.

> you
> provide a single 'deployment descriptor' which indicates the entire
> collection of URI where things are located on the web and the installer
> goes there, grabs everything it needs and installs. But that's just one
> xml file, not another package (it reduces the need for multipackaging
> and makes it easier for us to publish blocks and create
> web-service-driven repositories for behavior-based block shopping).
.....
> > This things are currently implemented in Phoenix, but in kernel space. I
> > agree that these features should be implemented in application space,
> > having a Cocoon specific implementation but service oriented.
>
> 'web service' oriented, I would say.
>
> My personal idea of a 'web service' is not just a way to have CORBA
> implemented in XML over HTTP, but a way to provide *all* the information
> one needs to use that web service. That requires not only logic, but
> also all the resources (images, stylesheets, static pages, help
> documents, etc..) that are required by the *user* of that service
> (either a human directly or another web service)
......
> Of course, I totally agree on the concept, but I don't think that
> Phoenix is capable of providing solution for all our needs since Avalon
> Blocks are very different from Cocoon Blocks (even if they aim use the
> same design patterns).

Of course they would be different, and they should be. All I'm saying is that 
Cocoon blocks would be deployed into a service (not web service) oriented 
framework like Phoenix is, where Cocoon container would be just another 
Phoenix service.

Please have a look at how James uses Phoenix, or how HP app. server uses 
their core service framework (very similar to Phoenix).
Source code is available at: 
http://www.bluestone.com/SaISAPI.dll/SaServletEngine.class/products/downloads.jsp.

Mircea

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: New commiters

[Ivelin Ivanov <iv...@iname.com>]

I just received my CVS access account.

I want to thank everyone who voted +1.

I will be checking in my CocoonForm code. It is a set of 2 working demos,
demonstrating Form binding and validation, based on XPath and Schematron.

The code is intended for demonstration of technology feasibility. Not
finalized in any case.
Torsten's Preceptor code is another alternative solution of the same
problem, which is checked in already.

I would ask anyone interested in the subject to look at the demos and
provide feedback.

As you are aware, Torsten, Konstantin and myself are in active discussions
offline the list in an effort to merge our solutions into a solid API that
would be ultimately proposed for a core Cocoon component.

Best regards,

Ivelin



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] Cocoon Blocks and internal web services

[Mircea Toma <mi...@apache.org>]

From: "Stefano Mazzocchi" <st...@apache.org>

> Mircea Toma wrote:
>
> > I'm not saying that Phoenix blocks should be used to implement "Cocoon
> > services", they are not meant for that. Cocoon could use Phoenix very
much
> > how James uses it (mailets), or if an app. server would be build using
> > Phoenix (ejb deployment). Building on top of Phoenix doesn't mean that
Cocoon
> > cannot have it's own packaging scheme, I think it should because it
addresses
> > different concerns (web related).
>
> Ok, I see your point now.
>
> > ......
> > > In case you don't want the installer to go around shopping for this,
> >
> > This is an example of what a Phoenix service could do for Cocoon. Going
> > around and shop for blocks is not a web related service but a deployment
> > service thus easily implemented using a Phoenix block.
>
> Absolutely. I'm not saying that Cocoon shouldn't be Phoenix-aware or
> Phoenix friendly, rather the opposite, but these are completely separate
> concerns.

Yes, they are.

>
> > Things like: XML database, search engine, object store, servlet&JSP
engines,
> > or Cocoon container are well suited to be implemented as Phoenix blocks.
>
> In fact, Cocoon itself (with no cocoon blocks on top) can well be seen
> as one Avalon Block, but be easily integrated into Phoenix.

This was my point.
Cocoon container can focuse on managing webapp level components by using
Phoenix blocks/services (non web-related services like a ServletEngine or
XML db) not containing and managing them as it stands now.

.........
> > Of course they would be different, and they should be. All I'm saying is
that
> > Cocoon blocks would be deployed into a service (not web service)
oriented
> > framework like Phoenix is, where Cocoon container would be just another
> > Phoenix service.
>
> No, this is what I *don't* like. A cocoon block is not an extension of
> an Avalon block, but it's a totally different thing.

I'm not saying that Cocoon blocks are an extension of Phoenix blocks.
Phoenix blocks would provide container (kernel) services for Cocoon, thus
providing deployment and assembly services for Cocoon blocks.


> > Please have a look at how James uses Phoenix, or how HP app. server uses
> > their core service framework (very similar to Phoenix).
> > Source code is available at:
> >
http://www.bluestone.com/SaISAPI.dll/SaServletEngine.class/products/download
s.jsp.
>
> I'm all in favor of using/reusing Phoenix where it does make sense, but

Glad to hear that.
I volunteer to help with this!

> I don't think it does at this webapp level.

I don't think that either. I guess this misunderstaning is due to me
sidetracking the discussion thread.

Mircea


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] Cocoon Blocks and internal web services

[Stefano Mazzocchi <st...@apache.org>]

Mircea Toma wrote:

> I'm not saying that Phoenix blocks should be used to implement "Cocoon
> services", they are not meant for that. Cocoon could use Phoenix very much
> how James uses it (mailets), or if an app. server would be build using
> Phoenix (ejb deployment). Building on top of Phoenix doesn't mean that Cocoon
> cannot have it's own packaging scheme, I think it should because it addresses
> different concerns (web related).

Ok, I see your point now.

> ......
> > In case you don't want the installer to go around shopping for this,
> 
> This is an example of what a Phoenix service could do for Cocoon. Going
> around and shop for blocks is not a web related service but a deployment
> service thus easily implemented using a Phoenix block.

Absolutely. I'm not saying that Cocoon shouldn't be Phoenix-aware or
Phoenix friendly, rather the opposite, but these are completely separate
concerns.

> Things like: XML database, search engine, object store, servlet&JSP engines,
> or Cocoon container are well suited to be implemented as Phoenix blocks.

In fact, Cocoon itself (with no cocoon blocks on top) can well be seen
as one Avalon Block, but be easily integrated into Phoenix.
 
> > you
> > provide a single 'deployment descriptor' which indicates the entire
> > collection of URI where things are located on the web and the installer
> > goes there, grabs everything it needs and installs. But that's just one
> > xml file, not another package (it reduces the need for multipackaging
> > and makes it easier for us to publish blocks and create
> > web-service-driven repositories for behavior-based block shopping).
> ......
> > > This things are currently implemented in Phoenix, but in kernel space. I
> > > agree that these features should be implemented in application space,
> > > having a Cocoon specific implementation but service oriented.
> >
> > 'web service' oriented, I would say.
> >
> > My personal idea of a 'web service' is not just a way to have CORBA
> > implemented in XML over HTTP, but a way to provide *all* the information
> > one needs to use that web service. That requires not only logic, but
> > also all the resources (images, stylesheets, static pages, help
> > documents, etc..) that are required by the *user* of that service
> > (either a human directly or another web service)
> .......
> > Of course, I totally agree on the concept, but I don't think that
> > Phoenix is capable of providing solution for all our needs since Avalon
> > Blocks are very different from Cocoon Blocks (even if they aim use the
> > same design patterns).
> 
> Of course they would be different, and they should be. All I'm saying is that
> Cocoon blocks would be deployed into a service (not web service) oriented
> framework like Phoenix is, where Cocoon container would be just another
> Phoenix service.

No, this is what I *don't* like. A cocoon block is not an extension of
an Avalon block, but it's a totally different thing.
 
> Please have a look at how James uses Phoenix, or how HP app. server uses
> their core service framework (very similar to Phoenix).
> Source code is available at:
> http://www.bluestone.com/SaISAPI.dll/SaServletEngine.class/products/downloads.jsp.

I'm all in favor of using/reusing Phoenix where it does make sense, but
I don't think it does at this webapp level.

Anybody else wants to comment on this?

-- 
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: [RT] Cocoon Blocks and internal web services

[Berin Loritsch <bl...@apache.org>]

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org] 
> 
> > Do you mean here to replace ComponentManager/Selector with the CM 
> > interface discussed for future Excalibur release CM.select(String 
> > role,  Object query) where, in this case, query would be the URL?
> 
> I don't know. I'm currently not following Avalon development 
> due to lack of time and focus, the above isn't focused on 
> implementation but only on behavior and design.

The next-gen Framework is on hold.  We have an equivalent to CM/CS
called the ServiceManager and ServiceSelector (for lack of a better
name).  The only difference is that the Service** mechanisms do not
require your components to implement the Component interface.  This
was to address a need in several projects where the components used
were developed by third parties, and did not have the ability or
right to change the interfaces that the components/services used.

The ServiceManager/ServiceSelector mechanism works with Objects.
While you *can* use it a generic lookup service for any object,
it is not encouraged.  The purpose is for using components that
you have no access to the source code to change the interface.

Rest assured, in future versions of Framework, we will remove the need
for arbitrary marker interfaces--so that all interfaces actually have
a purpose.

Beyond that, there is not much you have to worry about.  Change is
slow in Avalon, because we want to make it useable for a wide audience.
We really don't want to break backwards compatibility if we can
help it.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] Cocoon Blocks and internal web services

[Stefano Mazzocchi <st...@apache.org>]

Mircea Toma wrote:
> 
> Hi,
> 
> ..............
> ..............
> 
> > This contract explicitly indicates:
> >
> >  1) web resources exposed by the block (for example files accessible
> > from other blocks)
> >  2) service components exposed by the block (for example avalon
> > components or sitemap components)
> 
> I don't want to start another hot-headed discussion, but IMO Phoenix
> provides already a framework for service components. Lifecycle management,
> logging, thread pools, class-loading management, and service
> assembly/interdependencies can be use for many parts of Cocoon. Cocoon does
> a good job at managing fine grained components (sitemap components), but
> fails in managing coarse grained components (service components). Example of
> services that can be imediatelly implemented as Phoenix blocks are
> components like:
> 
> Server.java (hsql db)
> JSPEngine.java
> RendererFactory.java
> LuceneCocoonIndexer.java
> LuceneCocoonSearcher.java
> TranscoderFactory.java
> XSLTProcessor.java
> Store.java
> StoreJanitor.java
> .....

Yes and no.

The intent is to use the same patterns that inspired the creation of
Phoenix (which are included in the original Avalon design that Pier,
Federico and I invented), but *not* to clone Phoenix!

This is because the 'service' concept that can be provided by a
collection of logic components is very different from the 'internal web
service' concept that a cocoon block should provide.

This different perspective, in fact, suggests different factorization of
blocks from the ones you outlined above, which are, in fact,
logic-oriented instead of 'concern-oriented'.

Implementation-wise, I'm pretty sure we might end up "using" parts of
Phoenix directly (or patch it to make it abstract enough to handle our
needs as well), but at a totally different level (app-level rather than
core-level) and driven by different needs and concerns.

> >
> > Each block contains a descriptor file (located in
> > /BLOCK-INF/block.xinfo) which indicates:
> >
> >  1) information about the block (author, version, original location,
> > license and all that other block metadata)
> >
> >  2) behavioral contract that the block implements (along with
> > information on mappings between the contract and this block's
> > implementation)
> >
> >  3) dependencies: this is a list of zero or more 'block contracts' upon
> > which the block depends.
> 
> Maybe I'm missing the point, but shouldn't be there another packaging level
> where all blocks are bundled together with roles, sitemap, and flowmap
> descriptors?

Yes, there must be a way to 'deploy a collection of blocks', just like
Phoenix does with 'server descriptors'.

But I don't see the need for another packaging level because the roles,
sitemaps and flowmaps are already contained in the blocks. So, say you
want to install a webmail block, you install that and the system goes
around and shops for the blocks on which the webmail depends on.

In case you don't want the installer to go around shopping for this, you
provide a single 'deployment descriptor' which indicates the entire
collection of URI where things are located on the web and the installer
goes there, grabs everything it needs and installs. But that's just one
xml file, not another package (it reduces the need for multipackaging
and makes it easier for us to publish blocks and create
web-service-driven repositories for behavior-based block shopping).

> >  a) have different implementations of the same block associated to
> > different blocks, so, for example, two different blocks might require a
> > 'skin' role, but each of them might have associated different
> > implementations of that role.
> 
> Do you mean here to replace ComponentManager/Selector with the CM interface
> discussed for future Excalibur release CM.select(String role,  Object query)
> where, in this case, query would be the URL?

I don't know. I'm currently not following Avalon development due to lack
of time and focus, the above isn't focused on implementation but only on
behavior and design.

> >  5) for each dependency, the block manager scans the registry of
> > currently installed blocks in the system. If a block that implements the
> > dependent contract is already installed, the user is ask to confirm its
> > use, otherwise, the block manager will look in the block repositories to
> > download the appropriate block and will ask the user to choose between a
> > list of compatible implementations of that role.
> 
> This things are currently implemented in Phoenix, but in kernel space. I
> agree that these features should be implemented in application space, having
> a Cocoon specific implementation but service oriented.

'web service' oriented, I would say.

My personal idea of a 'web service' is not just a way to have CORBA
implemented in XML over HTTP, but a way to provide *all* the information
one needs to use that web service. That requires not only logic, but
also all the resources (images, stylesheets, static pages, help
documents, etc..) that are required by the *user* of that service
(either a human directly or another web service)

> >
> > In case of deployment descriptors, the block manager can be asked to
> > install the system without performing checkings (but these are
> > implementation details)
> .......
> .......
> > At the same time, this description format is very well going to be so
> > complex that WSDL will look like piece of cake and I'm scared about
> > this.... on the other hand, it might enable things like form validation
> > and so on automatic and rather painless.
> 
> I know that I am biased towards using Phoenix as a framework to develop
> Cocoon using a service-oriented approach, but I think its a good way to
> manage the increasingly growing Cocoon code base.

Of course, I totally agree on the concept, but I don't think that
Phoenix is capable of providing solution for all our needs since Avalon
Blocks are very different from Cocoon Blocks (even if they aim use the
same design patterns).

-- 
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: [RT] Cocoon Blocks and internal web services

[Mircea Toma <mi...@apache.org>]

Hi,

.............
.............

> This contract explicitly indicates:
>
>  1) web resources exposed by the block (for example files accessible
> from other blocks)
>  2) service components exposed by the block (for example avalon
> components or sitemap components)

I don't want to start another hot-headed discussion, but IMO Phoenix
provides already a framework for service components. Lifecycle management,
logging, thread pools, class-loading management, and service
assembly/interdependencies can be use for many parts of Cocoon. Cocoon does
a good job at managing fine grained components (sitemap components), but
fails in managing coarse grained components (service components). Example of
services that can be imediatelly implemented as Phoenix blocks are
components like:

Server.java (hsql db)
JSPEngine.java
RendererFactory.java
LuceneCocoonIndexer.java
LuceneCocoonSearcher.java
TranscoderFactory.java
XSLTProcessor.java
Store.java
StoreJanitor.java
....

>
> Each block contains a descriptor file (located in
> /BLOCK-INF/block.xinfo) which indicates:
>
>  1) information about the block (author, version, original location,
> license and all that other block metadata)
>
>  2) behavioral contract that the block implements (along with
> information on mappings between the contract and this block's
> implementation)
>
>  3) dependencies: this is a list of zero or more 'block contracts' upon
> which the block depends.

Maybe I'm missing the point, but shouldn't be there another packaging level
where all blocks are bundled together with roles, sitemap, and flowmap
descriptors?

>
>                                     -- o --
>
> The resources exposed by blocks are accessed using a URI-compatible
> protocol description of the form:
>
>  block:[role]://path/resource
>
> where
>
>  block: -> identifies the protocol
>  [role] -> identifies the block in the current context and it's a short
> identifier that maps to the fully-qualifying URI that identifies the
> block contract.
>
> For example, suppose we have something like this:
>
>  <map:transform src="block:skin://xslt/document2html.xslt">
>
> the block role 'skin' must be translated to a fully qualifying URI (much
> similar to the prefix -> URI translation that happens for XML
> namespaces).
>
> This is done by adding the following semantics to the sitemap:
>
>  <map:blocks>
>   <map:block role="skin"
> uri="http://apache.org/cocoon/blocks/skin/2.1"/>
>  </map:blocks>
>
> After this translation is performed, the 'block:' protocol handler will
> have to identifiy the resource and retrieve it from the block archive
> (which can be extracted or left compressed, this should not change
> behavior since the blocks are not allowed to write in their own
> addressing space directly).
>
> This mapping is performed by the block deployer, which has the
> information on how to map this URI to the block that was installed to
> operate that contract for the requesting block.
>
> This futher decoupling is the key to the polymorphic behavior of blocks:
> in fact, the block "role" identifies a contract, not an actual
> implementation and it's therefore entirely possible to:
>
>  a) have different implementations of the same block associated to
> different blocks, so, for example, two different blocks might require a
> 'skin' role, but each of them might have associated different
> implementations of that role.

Do you mean here to replace ComponentManager/Selector with the CM interface
discussed for future Excalibur release CM.select(String role,  Object query)
where, in this case, query would be the URL?

>
>  b) share the same implementation between different blocks.
>
>  c) hot-deploy/hot-update a block implementation simply by changing the
> last mapping translation.
>
>                                     -- o --
>
> The logic components exposed by the blocks are located exactly as
> before, using fully qualified dot-notation for java classes. All
> translation and mapping will be automatically performed by the
> classloaders.
>
> So, for example, if Block A does
>
>  <map:generator type="mygen" class="com.mystuff.whatever.Generator"/>
>
> the classloader responsible for Block A will look for that class in the
> /BLOCK-INF/lib or /BLOCK-INF/classes directories and included jar
> archives of the blocks on which this Block A depends on.
>
>                                     -- o --
>
> Here I describe a potential use of a block-based cocoon system:
>
>  1) let us suppose that Cocoon is already installed in a servlet
> container and up and running.
>
>  2) let us suppose that we have a tool that implements block
> management/deployment on top of Cocoon [how this is implemented is not
> important for our current needs]
>
>  3) the user has three ways to install new blocks:
>
>     - provide the block manager with a URI where the block archive is
> located on the web
>
>     - have the block manager discover and locate a block repository,
> which will be a web service that will interact with the block manager
> and list information on new blocks and all that (sort of apt-get)
>
>     - provide the block manager with a 'block deployment descriptor'
> which contains an 'installable' and complete dependency set of blocks
> that implement a given web application. (this is to ease installation)
>
>  4) once the user has choosen what block/s to install, the block manager
> downloads it/them from the internet and reads its metadata to find out
> eventual dependencies.
>
>  5) for each dependency, the block manager scans the registry of
> currently installed blocks in the system. If a block that implements the
> dependent contract is already installed, the user is ask to confirm its
> use, otherwise, the block manager will look in the block repositories to
> download the appropriate block and will ask the user to choose between a
> list of compatible implementations of that role.

This things are currently implemented in Phoenix, but in kernel space. I
agree that these features should be implemented in application space, having
a Cocoon specific implementation but service oriented.

>
> In case of deployment descriptors, the block manager can be asked to
> install the system without performing checkings (but these are
> implementation details)
......
......
> At the same time, this description format is very well going to be so
> complex that WSDL will look like piece of cake and I'm scared about
> this.... on the other hand, it might enable things like form validation
> and so on automatic and rather painless.

I know that I am biased towards using Phoenix as a framework to develop
Cocoon using a service-oriented approach, but I think its a good way to
manage the increasingly growing Cocoon code base.

Mircea


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] Cocoon Blocks and internal web services

[Stefano Mazzocchi <st...@apache.org>]

Jeremy Quinn wrote:
> 
> At 2:26 pm +0200 4/4/02, Stefano Mazzocchi wrote:
> >> Well, SoC isn't just about who writes the Java code. Offering a clean
> >> Java API to the block (role) authors for defining the validation rules
> >> might be better than offering an "insanely complex" XML API. Our main
> >> concern is to perform the validation in a uniform way according to these
> >> rules.
> >
> >Yes, but it's a matter of *trust* more than SoC at this point: I give
> >you the contract, you give me the implementation *and* a way to check
> >the validation.
> >
> >As italian, I'm always very sensible at cheating :)
>                              ^^^^^^^^^^^^^^^^^^^^
> 
> Hi Stefano,
> 
> I believe you meant to say "sensitive to cheating"?
> 
> Otherwise you said:
> 
> "As an Italian I always cheat in a very calm, intelligent and appropriate way"
> 
>  ;)

Right.

Well, to be honest, even the other meaning can be appropriate at times
:)

-- 
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: [RT] Cocoon Blocks and internal web services

[Stefano Mazzocchi <st...@apache.org>]

Antti Koivunen wrote:
> 
> Stefano Mazzocchi wrote:
> > Antti Koivunen wrote:
> >
> >>Stefano Mazzocchi wrote:
> >>>
> >>>1) no description: blocks identify their contract with an URI that
> >>>that's it, there is no way to validate the fact that a block implements
> >>>a specified contract, this is the weakest form of contract. It's easier
> >>>to implement and places the burden of validation at runtime.
> >>
> >>Probably not enough, but must be possible, i.e. the block manager must
> >>provide a way to turn off validation for certain blocks.
> >
> >
> > Hmmm, ... but shouldn't we force block compliance automatically? just
> > like you can't turn off interface checking when you compile your java
> > code?
> 
> Well, this is a bit different. It might be quite convenient during
> development, e.g. the deployment is faster and it's possible to
> add/remove features without having to update the descriptor every time.

Good point.

> Also, if the URI is used to locate the descriptor, there's always the
> possibility that you're offline or behind a firewall (although the block
> manager should provide a way around this by giving the option of storing
> the descriptor locally).

Yes, of course.

> Of course, I agree that strong compliance checking is a good idea. My
> point here was convenience in certain situations. Possible modes of
> operation could include:
> 
>    1. Validate everything. Only the resources explicitly defined in the
>       descriptor are available.
> 
>    2. Check dependencies but allow the block to be queried for resources
>       not explicitly defined in the descriptor.
> 
>    3. Only check the URI. All other validation occurs at runtime.
> 
> >>>2) little description: the contract identifier indicates the 'skeleton'
> >>>of the contract but doesn't declare more detailed behavior. There is a
> >>>way to perform structure validation on the blocks and also a way to
> >>>auto-document the block contract itself, but the behavioral validation
> >>>cannot be automated and it's left to the user checking at runtime.
> >>
> >>I think we should provide this, at least, e.g. the following would
> >>actually go a long way:
> >>
> >>   <provides-file name="xslt/document2html.xslt"/>
> >>   <provides-implementation interface="com.mystuff.MyThing"/>
> >
> >
> > Yes, this is where I aim to start.
> 
> Very good.
> 
> >>>3) detailed description: the contract identifier indicates both the
> >>>skeleton and the behavior of the contract. This allows high granular
> >>>automatic validation.
> >>
> >>Sounds good, but would be difficult to implement using just an XML
> >>descriptor.
> >
> >
> > If you are saying that the XML descriptor might get insanely complex, I
> > totally agree.
> 
> Exactly my point, but as said before, a few simple validation rules
> would go a long way (but probably not all the way).
> 
> >>Following proper SoC, perhaps the role itself should provide
> >>the tools for more complex validation.
> >
> >
> > No, this *breaks* SoC! Validation is not your concern is *our* to
> > understand if what  you provided us with works depending on the contract
> > that we are expecting!
> 
> Well, SoC isn't just about who writes the Java code. Offering a clean
> Java API to the block (role) authors for defining the validation rules
> might be better than offering an "insanely complex" XML API. Our main
> concern is to perform the validation in a uniform way according to these
> rules.

Yes, but it's a matter of *trust* more than SoC at this point: I give
you the contract, you give me the implementation *and* a way to check
the validation.

As italian, I'm always very sensible at cheating :)

> >>The role descriptor could make
> >>use of the simple built-in validators (see above) and/or define custom
> >>ones if necessary.
> >>
> >>It should be possible to define an 'intermediate' API to make it easy to
> >>implement new validators, e.g.
> >>
> >>   interface Validator
> >>   {
> >>       void validate( ValidationContext ctx ) throws ValidationException;
> >>   }
> >>
> >>   interface ValidationContext
> >>   {
> >>       BlockInfo getBlockInfo();
> >>       URL getResource( String name );
> >>       ClassLoader getContextClassLoader();
> >>       Configuration getConfiguration();  // from the role descriptor
> >>   }
> >>
> >>This approach would allow practically any level complexity, but would
> >>also mean that the role might not consist of just the XML descriptor,
> >>i.e. we might end up with another archive format, say '.cor'. Still,
> >>it's probably be better than trying to please everybody and ending up
> >>with 50kB role descriptors.
> >
> >
> > Hmmm, no, I was thinking more of using namespaces to trigger different
> > validation behavior during installation.
> 
> I'm also quite hesitant to go beyond XML, but it might be difficult to
> define standalone roles. Consider the following fairly simple example:
> 
>    <validate-xml file="foo.xml" schema="http://mystuff.com/xfoo"/>
> 
> Now, if the schema URI does not resolve to a valid schema (or there's no
> internet access or the server is down), we have a problem. There are a
> couple of possible solutions (pre-install the schema, require momentary
> internet access), but wouldn't it be more convenient to download a
> single file that contains everything? Then we could do something like:
> 
>    <validate-xml file="block:foo.xml" schema="role:schema/xfoo.xsd"/>
> 
> This is just one example, but I'm pretty sure there other similar
> situations.

Ok, I'll try to come up with something as soon as I have time.

Ciao

-- 
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: [RT] Cocoon Blocks and internal web services

[Antti Koivunen <an...@users.sourceforge.net>]

Stefano Mazzocchi wrote:
> Antti Koivunen wrote:
> 
>>Stefano Mazzocchi wrote:
>>>
>>>1) no description: blocks identify their contract with an URI that
>>>that's it, there is no way to validate the fact that a block implements
>>>a specified contract, this is the weakest form of contract. It's easier
>>>to implement and places the burden of validation at runtime.
>>
>>Probably not enough, but must be possible, i.e. the block manager must
>>provide a way to turn off validation for certain blocks.
> 
> 
> Hmmm, ... but shouldn't we force block compliance automatically? just
> like you can't turn off interface checking when you compile your java
> code?

Well, this is a bit different. It might be quite convenient during 
development, e.g. the deployment is faster and it's possible to 
add/remove features without having to update the descriptor every time. 
Also, if the URI is used to locate the descriptor, there's always the 
possibility that you're offline or behind a firewall (although the block 
manager should provide a way around this by giving the option of storing 
the descriptor locally).

Of course, I agree that strong compliance checking is a good idea. My 
point here was convenience in certain situations. Possible modes of 
operation could include:

   1. Validate everything. Only the resources explicitly defined in the
      descriptor are available.

   2. Check dependencies but allow the block to be queried for resources
      not explicitly defined in the descriptor.

   3. Only check the URI. All other validation occurs at runtime.


>>>2) little description: the contract identifier indicates the 'skeleton'
>>>of the contract but doesn't declare more detailed behavior. There is a
>>>way to perform structure validation on the blocks and also a way to
>>>auto-document the block contract itself, but the behavioral validation
>>>cannot be automated and it's left to the user checking at runtime.
>>
>>I think we should provide this, at least, e.g. the following would
>>actually go a long way:
>>
>>   <provides-file name="xslt/document2html.xslt"/>
>>   <provides-implementation interface="com.mystuff.MyThing"/>
> 
> 
> Yes, this is where I aim to start.

Very good.


>>>3) detailed description: the contract identifier indicates both the
>>>skeleton and the behavior of the contract. This allows high granular
>>>automatic validation.
>>
>>Sounds good, but would be difficult to implement using just an XML
>>descriptor. 
> 
> 
> If you are saying that the XML descriptor might get insanely complex, I
> totally agree.

Exactly my point, but as said before, a few simple validation rules 
would go a long way (but probably not all the way).


>>Following proper SoC, perhaps the role itself should provide
>>the tools for more complex validation. 
> 
> 
> No, this *breaks* SoC! Validation is not your concern is *our* to
> understand if what  you provided us with works depending on the contract
> that we are expecting!

Well, SoC isn't just about who writes the Java code. Offering a clean 
Java API to the block (role) authors for defining the validation rules 
might be better than offering an "insanely complex" XML API. Our main 
concern is to perform the validation in a uniform way according to these 
rules.


>>The role descriptor could make
>>use of the simple built-in validators (see above) and/or define custom
>>ones if necessary.
>>
>>It should be possible to define an 'intermediate' API to make it easy to
>>implement new validators, e.g.
>>
>>   interface Validator
>>   {
>>       void validate( ValidationContext ctx ) throws ValidationException;
>>   }
>>
>>   interface ValidationContext
>>   {
>>       BlockInfo getBlockInfo();
>>       URL getResource( String name );
>>       ClassLoader getContextClassLoader();
>>       Configuration getConfiguration();  // from the role descriptor
>>   }
>>
>>This approach would allow practically any level complexity, but would
>>also mean that the role might not consist of just the XML descriptor,
>>i.e. we might end up with another archive format, say '.cor'. Still,
>>it's probably be better than trying to please everybody and ending up
>>with 50kB role descriptors.
> 
> 
> Hmmm, no, I was thinking more of using namespaces to trigger different
> validation behavior during installation.

I'm also quite hesitant to go beyond XML, but it might be difficult to 
define standalone roles. Consider the following fairly simple example:

   <validate-xml file="foo.xml" schema="http://mystuff.com/xfoo"/>

Now, if the schema URI does not resolve to a valid schema (or there's no 
internet access or the server is down), we have a problem. There are a 
couple of possible solutions (pre-install the schema, require momentary 
internet access), but wouldn't it be more convenient to download a 
single file that contains everything? Then we could do something like:

   <validate-xml file="block:foo.xml" schema="role:schema/xfoo.xsd"/>

This is just one example, but I'm pretty sure there other similar 
situations.

(: A ;)




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] Cocoon Blocks and internal web services

[Stefano Mazzocchi <st...@apache.org>]

Antti Koivunen wrote:
> 
> Stefano Mazzocchi wrote:
> > Now that Cocoon 2.0.2 is out of the door, I think it's time that we
> > continue the discussion on Cocoon Blocks, which, IMO, represent the
> > major step forward that we should aim for Cocoon 2.1.
> >
> > Thanks to all of those who helped me shaping up the cocoon block idea.
> 
> In case that includes me, you're very welcome :) 

Yes, it does :)

> I actually meant to get
> back to you earlier, but found myself insanely busy. Anyway, here goes...
> 
> <snipped-a-lot-of-good-stuff-that-requires-no-further-comment-at-this-stage/>
> 
> > So, what level of description we need for our block contracts?
> >
> > I see several levels:
> >
> > 1) no description: blocks identify their contract with an URI that
> > that's it, there is no way to validate the fact that a block implements
> > a specified contract, this is the weakest form of contract. It's easier
> > to implement and places the burden of validation at runtime.
> 
> Probably not enough, but must be possible, i.e. the block manager must
> provide a way to turn off validation for certain blocks.

Hmmm, ... but shouldn't we force block compliance automatically? just
like you can't turn off interface checking when you compile your java
code?

> > 2) little description: the contract identifier indicates the 'skeleton'
> > of the contract but doesn't declare more detailed behavior. There is a
> > way to perform structure validation on the blocks and also a way to
> > auto-document the block contract itself, but the behavioral validation
> > cannot be automated and it's left to the user checking at runtime.
> 
> I think we should provide this, at least, e.g. the following would
> actually go a long way:
> 
>    <provides-file name="xslt/document2html.xslt"/>
>    <provides-implementation interface="com.mystuff.MyThing"/>

Yes, this is where I aim to start.

> > 3) detailed description: the contract identifier indicates both the
> > skeleton and the behavior of the contract. This allows high granular
> > automatic validation.
> 
> Sounds good, but would be difficult to implement using just an XML
> descriptor. 

If you are saying that the XML descriptor might get insanely complex, I
totally agree.

> Following proper SoC, perhaps the role itself should provide
> the tools for more complex validation. 

No, this *breaks* SoC! Validation is not your concern is *our* to
understand if what  you provided us with works depending on the contract
that we are expecting!

> The role descriptor could make
> use of the simple built-in validators (see above) and/or define custom
> ones if necessary.
> 
> It should be possible to define an 'intermediate' API to make it easy to
> implement new validators, e.g.
> 
>    interface Validator
>    {
>        void validate( ValidationContext ctx ) throws ValidationException;
>    }
> 
>    interface ValidationContext
>    {
>        BlockInfo getBlockInfo();
>        URL getResource( String name );
>        ClassLoader getContextClassLoader();
>        Configuration getConfiguration();  // from the role descriptor
>    }
> 
> This approach would allow practically any level complexity, but would
> also mean that the role might not consist of just the XML descriptor,
> i.e. we might end up with another archive format, say '.cor'. Still,
> it's probably be better than trying to please everybody and ending up
> with 50kB role descriptors.

Hmmm, no, I was thinking more of using namespaces to trigger different
validation behavior during installation.
 
> So, the best approach might actually be 1+2+3 :)

no, 3 extends 2 and 1 should not be allowed, IMO.

-- 
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: [RT] Cocoon Blocks and internal web services

[Antti Koivunen <an...@users.sourceforge.net>]

Stefano Mazzocchi wrote:
> Now that Cocoon 2.0.2 is out of the door, I think it's time that we
> continue the discussion on Cocoon Blocks, which, IMO, represent the
> major step forward that we should aim for Cocoon 2.1.
> 
> Thanks to all of those who helped me shaping up the cocoon block idea.

In case that includes me, you're very welcome :) I actually meant to get 
back to you earlier, but found myself insanely busy. Anyway, here goes...

<snipped-a-lot-of-good-stuff-that-requires-no-further-comment-at-this-stage/>

> So, what level of description we need for our block contracts?
> 
> I see several levels:
> 
> 1) no description: blocks identify their contract with an URI that
> that's it, there is no way to validate the fact that a block implements
> a specified contract, this is the weakest form of contract. It's easier
> to implement and places the burden of validation at runtime.

Probably not enough, but must be possible, i.e. the block manager must 
provide a way to turn off validation for certain blocks.

> 2) little description: the contract identifier indicates the 'skeleton'
> of the contract but doesn't declare more detailed behavior. There is a
> way to perform structure validation on the blocks and also a way to
> auto-document the block contract itself, but the behavioral validation
> cannot be automated and it's left to the user checking at runtime.

I think we should provide this, at least, e.g. the following would 
actually go a long way:

   <provides-file name="xslt/document2html.xslt"/>
   <provides-implementation interface="com.mystuff.MyThing"/>

> 3) detailed description: the contract identifier indicates both the
> skeleton and the behavior of the contract. This allows high granular
> automatic validation.

Sounds good, but would be difficult to implement using just an XML 
descriptor. Following proper SoC, perhaps the role itself should provide 
the tools for more complex validation. The role descriptor could make 
use of the simple built-in validators (see above) and/or define custom 
ones if necessary.

It should be possible to define an 'intermediate' API to make it easy to 
implement new validators, e.g.

   interface Validator
   {
       void validate( ValidationContext ctx ) throws ValidationException;
   }

   interface ValidationContext
   {
       BlockInfo getBlockInfo();
       URL getResource( String name );
       ClassLoader getContextClassLoader();
       Configuration getConfiguration();  // from the role descriptor
   }

This approach would allow practically any level complexity, but would 
also mean that the role might not consist of just the XML descriptor, 
i.e. we might end up with another archive format, say '.cor'. Still, 
it's probably be better than trying to please everybody and ending up 
with 50kB role descriptors.

So, the best approach might actually be 1+2+3 :)

(: A ;)

-- 
Antti Koivunen (Mr.) <an...@users.sf.net>
---------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] Cocoon Blocks and internal web services

[Stefano Mazzocchi <st...@apache.org>]

Greg Weinger wrote:
> 
> > But this is not enough: behavioral description *depends* on
> > the type of the exposed resource.
> >
> > For example, a resource such as
> >
> >  block:skin://xslt/document2html
> >
> > will have to expose the returning MIME-type (XSLT in this
> > case) as well as it's schema, as well as the schema of the
> > conten that it's capable of transforming and the schema of
> > the content that is capable of generating after the transformation.
> 
> How difficult would it be write code that automatically generates these
> "entry" and "exit" xml schema contracts for a stylesheet?

Well, honestly I don't know: everything I start thinking about something
like that I don't even reach half of the complexity that my minds blows
up and you know I'm not that new to high level abstractions :)

But it seems to me it's probably one of the most complex things *ever*
in the realm of structured languaged, but I'm wide open to suggestions.

> The block
> deployment code could create them for you.  For hard-coded components,
> it's up to the developer.
> 
> The converse would also be useful; like a generic unit test for a
> stylesheet, based on these "entry" and "exit" schemas, it would
> determine if the stylesheet "satisfies" the contract.
> 
> I am working on a cocoon application with dynamically pluggable
> stylesheets that needs something like that.  Without any kind of
> validation, the system is just too brittle, and anyone who writes a bad
> stylesheet can wreak havoc.

Yes, I'm totally aware of this, but I'm not sure you understand the
complexity of the problem. Suppose you have something like this:

 A -> [1] -> B

where A,B are two XML documents and [1] is an XSLT stylesheet.

The first thing to say is that the validation engine must be namespace
capable, this automatically rules out DTDs. My personal suggestion,
since this is a validation phase and shouldn't mess with the infoset,
would be to use RelaxNG.

But other than that I get stuck :/

Scott, Norm, do you have any useful information for us on this subject?
I mean: did you guys in the XSLT WG ever thought about 'validating' the
stylesheet behavior against a pipeline flow rather than validating the
stylesheet *itself*?

-- 
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: [RT] Cocoon Blocks and internal web services

[Greg Weinger <gw...@itmedicine.net>]

> But this is not enough: behavioral description *depends* on 
> the type of the exposed resource.
> 
> For example, a resource such as 
> 
>  block:skin://xslt/document2html
> 
> will have to expose the returning MIME-type (XSLT in this 
> case) as well as it's schema, as well as the schema of the 
> conten that it's capable of transforming and the schema of 
> the content that is capable of generating after the transformation.

How difficult would it be write code that automatically generates these
"entry" and "exit" xml schema contracts for a stylesheet?  The block
deployment code could create them for you.  For hard-coded components,
it's up to the developer.

The converse would also be useful; like a generic unit test for a
stylesheet, based on these "entry" and "exit" schemas, it would
determine if the stylesheet "satisfies" the contract.

I am working on a cocoon application with dynamically pluggable
stylesheets that needs something like that.  Without any kind of
validation, the system is just too brittle, and anyone who writes a bad
stylesheet can wreak havoc.  

--Greg



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org