lenya-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gringinho <gringi...@gmail.com>
Subject Re: [2.0.1] XML namespace prefix confusion in LenyaMetaDataGenerator.java for the Collections module and MetaDataTransformer.java xmlns URI oddity
Date Sun, 20 Apr 2008 05:34:27 GMT
On Sat, Apr 19, 2008 at 11:52 AM, Andreas Hartmann <andreas@apache.org> wrote:
> Hi Gringinho,
> thanks a lot for bringing this up. I agree that the current situation causes confusion.
>
> Gringinho schrieb:
> [...]
> > Can I suggest that the lenya:metadata prefix is dropped from LenyaMetaDataGenerator.java
,
> > or that a more appropriate meta:metadata prefix is used ?
> >
> +1 to use the meta: prefix.
>
> > Secondly - the xmlns:meta URI used in the standard page2xhtml.xsl is different
> > from the normal xmlns:meta="http://apache.org/cocoon/lenya/metadata/1.0"
> > used in other stylesheets around Lenya.
> >
> > The only places that the URI http://apache.org/lenya/meta/1.0/ is
> > mentioned are in
> > MetaDataTransformer.java
> > pubs/default/sitemap.xmap
> > pubs/default/xslt/page2xhtml.xsl
> >
> > Everywhere else the metadata element and xmlns:meta prefix are all associated with
> > the URI http://apache.org/cocoon/lenya/metadata/1.0 .
> >
>
> This URI uses the old convention from the times when we were a Cocoon sub-project. I
suggest the following:
>
> - Declare the LenyaMetaDataGenerator as deprecated
> - Introduce a MetaDataGenerator which uses http://apache.org/lenya/meta/1.0/ as output
namespace
>
> Or would it be better to use different namespaces for the generator and the transformer?
>

Well, the problem that I ran into - and that I think needs to be addressed,
is using these namespaces and prefixes together in a XSL stylesheet
like page2xhtml.xsl.
I got a lenya: prefixed source of metadata (collections) that I
aggregated via a sitemap,
and was using this - but at the same time I had other lenya: prefixed sources,
that use the page-envelope URI. Of course, it's possible to transform
and drop prefixes etc,
but that doesn't make it any easier for newbies like me, and I didn't
immediately get the
difference before having debugged for some time. ;)

So, as long as the meta: prefix means metadata with predictable
connotations and elements,
that makes life easier. The same goes for the lenya: prefix.
If "http://apache.org/lenya/meta/1.0/" is going to be the preferred
URI, having it
standardized all over makes it a lot easier when trying to get to
grasps with Lenya.

I was reading over your roadmap graded goals, and was thinking how
Lenya would be
easier for newbies. One great thing and strength of Lenya is the
adherence to standards.
For newcomers to Lenya - it's great if they can do a lot with XSLT,
and not need to
delve into the making of custom modules straight away.

The strategy of letting a lot be decided and made with XSL
stylesheets, also makes Lenya
more accessible to more people - who might not possess good Java
skills - effectively
broadening the user base.

Therefore, making sure that prefixes and namespaces are coherent
will ease this route for newcomers, and making modules flexible and
offer a lot of variable
to input makes great sense. This goes for getting user-names,
group-names and other
metadata about documents. Having eternal full user-names like
Solprovider mentioned,
makes a lot of sense. Also having pipelines that are flexible in how
to obtain resources,
so they can be mixed and matched via sitemaps and XSLT.

Of course, it's even more poweful to use the APIs and do a lot in
Java, but being new to
Lenya - even knowing your way around Java - the number of APIs between
Cocoon, Lenya
and all the subprojects that are applicable in a context is a pretty
daunting prospect.
Otherwise, I think the JCR Jackrabbit is a killer feature that will be
even more important
and make it even easier for those who focus more on the sitemap, XSLT, CSS route
to making a custom site. Even having easier entry for webservices with
more examples.

Oh, and perhaps being able to easily override views for modules,
without having to replicate
the whole module into another name. Views are pretty straightforward
to grasp and extend.
Hehe, I know someone have to do all this too - and it doesn't just pop
up magically when
we think of it, but it would be a nice goal for lowering the bar a
little, and I'll try and contribute
as I get more hang of dealing with Lenya.

Cheers,
Gringinho

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org


Mime
View raw message