RT : adding namespace to component's name.

[TREGAN Fabien <fa...@airbus.aeromatra.com>]

about components name, the doc says :

"name - Gives the component an identifying name by which it may be
referenced in the pipeline section."

So the name seems to be a shortcut to a personnal component.

But I think that the name is often used only to describe the component you
want to be called, without knowing it's class. (factory-like)

So I think we should hade namespace prefixes to component names in order to
:
-define one namespace for cocoon standards components (an another one for
each cocoon sample-specific component :) )
-avoid problems when differents cocoon-app will be deployed on the same
server.

Am I really wrong ?

ft.

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

Re: RT : adding namespace to component's name.

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

TREGAN Fabien wrote:
> about components name, the doc says :
> 
> "name - Gives the component an identifying name by which it may be
> referenced in the pipeline section."
> 
> So the name seems to be a shortcut to a personnal component.
> 
> But I think that the name is often used only to describe the component you
> want to be called, without knowing it's class. (factory-like)
> 
> So I think we should hade namespace prefixes to component names in order to
> :
> -define one namespace for cocoon standards components (an another one for
> each cocoon sample-specific component :) )
> -avoid problems when differents cocoon-app will be deployed on the same
> server.
> 
> Am I really wrong ?


I have wrestled with questions like this.  Should the component have a
namespace attached, or should there be a standard namespace for all
components.

In order to answer this question, we have to understand what the purpose
of Namespaces are.  Namespaces came around in order to allow XML
fragments from varying schemas to be mixed into one document.  Part of
the reason was to support XInclude semantics and other things along
those lines.

So in answer to your question, either every component has its own
namespace, or they all share the same namespace.

Let me further explain why.  If every component type (i.e. role)
has its own schema, then we can allow validation at the XML level
for component configurations.  However, we now have a very cluttered
configuration file.  That is clearly not what we want.

If every component has the same namespace, then it must follow the
semantics of the container.  This is where we are now.  We really
can't differentiate between user components and cocoon components
because it will serve to confuse the current container (ECM).

I would like to see a balance somewhere in the middle, but I really
don't see it happening.

Namespaces will not "avoid problems when different cocoon-apps will
be deployed on the same server".  That is taken care of by the
heirarchical nature of the Sitemap containers.




-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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