You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/09/23 12:04:02 UTC
[excalibur] Catalog code
Hi,
I just had a look at Cocoons Catalog manager code and noticed it used Suns
code. Considering the original code is in the public domain and Suns is under
a less than desirable license I was wondering what advantage Suns code had?
Would there be any advantage of using arbortexts PDed code directly? I was
thinking of adding it into Excalibur CVS and integrating it with some of our
stuff. Anyone care to enlighten me why this may be a bad idea? ;)
--
Cheers,
Pete
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [excalibur] Catalog code
Posted by David Crossley <cr...@indexgeo.com.au>.
When we first started to add catalogs capability to Cocoon
as proof-of-concept we used the Abortext code (i did not
know of the existence of any other code). Dims then added
the actual capability using the Sun package. I gather that
the Sun code is the evolution of the Arbortext package
(both are written by Norm Walsh). So there are many code
improvements and that would be the base for the future.
If the license of the new package is not suitable, then it may
be appropriate to approach Norm about changing it. I am
sure that the intent is to get entity resolution capability into
as wide usage as possible.
See documentation URLs below.
regards, David Crossley
Jeff Turner wrote:
> Peter Donald wrote:
> > Hi,
> >
> > I just had a look at Cocoons Catalog manager code and noticed it used
Suns
> > code. Considering the original code is in the public domain and Suns is
under
> > a less than desirable license I was wondering what advantage Suns code
had?
> > Would there be any advantage of using arbortexts PDed code directly? I
was
> > thinking of adding it into Excalibur CVS and integrating it with some of
our
> > stuff. Anyone care to enlighten me why this may be a bad idea? ;)
>
> I found a few minor bugs with the arbortext code (eg debug flags not getting
> propagated), and one major bug (DOCTYPE doesn't work), which I mailed Norm
> Walsh about. He said DOCTYPE would never work under XML due to namespace
> issues, and mentioned that the Sun version had been "substantially
modified",
> whatever that means.
>
> Anyway, I think it would be excellent to get *some* version of that catalog
> code in under Jakarta, because it's darn useful stuff, and it doesn't have a
> home. People all over the world are poking around in that code, discovering
the
> same bugs and limitations, and fixing them individually.
>
> I've put an Ant-buildable version of the arbortext code at:
>
> http://newgate.socialchange.net.au/~jeff/misc/catalog.tar.gz
>
> --Jeff
>
> Btw, for those who are wondering what the fuss is about, read:
>
http://www.arbortext.com/Think_Tank/XML_Resources/Issue_Three/issue_three.html
Also read the Cocoon 2 xdocs/catalog.xml and its associated
demonstration sample. The Sun resolver code also includes
an evolved version of that Arbortext Think Tank article.
http://www.sun.com/xml/developers/resolver/
> > --
> > Cheers,
> >
> > Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [excalibur] Catalog code
Posted by David Crossley <cr...@indexgeo.com.au>.
When we first started to add catalogs capability to Cocoon
as proof-of-concept we used the Abortext code (i did not
know of the existence of any other code). Dims then added
the actual capability using the Sun package. I gather that
the Sun code is the evolution of the Arbortext package
(both are written by Norm Walsh). So there are many code
improvements and that would be the base for the future.
If the license of the new package is not suitable, then it may
be appropriate to approach Norm about changing it. I am
sure that the intent is to get entity resolution capability into
as wide usage as possible.
See documentation URLs below.
regards, David Crossley
Jeff Turner wrote:
> Peter Donald wrote:
> > Hi,
> >
> > I just had a look at Cocoons Catalog manager code and noticed it used
Suns
> > code. Considering the original code is in the public domain and Suns is
under
> > a less than desirable license I was wondering what advantage Suns code
had?
> > Would there be any advantage of using arbortexts PDed code directly? I
was
> > thinking of adding it into Excalibur CVS and integrating it with some of
our
> > stuff. Anyone care to enlighten me why this may be a bad idea? ;)
>
> I found a few minor bugs with the arbortext code (eg debug flags not getting
> propagated), and one major bug (DOCTYPE doesn't work), which I mailed Norm
> Walsh about. He said DOCTYPE would never work under XML due to namespace
> issues, and mentioned that the Sun version had been "substantially
modified",
> whatever that means.
>
> Anyway, I think it would be excellent to get *some* version of that catalog
> code in under Jakarta, because it's darn useful stuff, and it doesn't have a
> home. People all over the world are poking around in that code, discovering
the
> same bugs and limitations, and fixing them individually.
>
> I've put an Ant-buildable version of the arbortext code at:
>
> http://newgate.socialchange.net.au/~jeff/misc/catalog.tar.gz
>
> --Jeff
>
> Btw, for those who are wondering what the fuss is about, read:
>
http://www.arbortext.com/Think_Tank/XML_Resources/Issue_Three/issue_three.html
Also read the Cocoon 2 xdocs/catalog.xml and its associated
demonstration sample. The Sun resolver code also includes
an evolved version of that Arbortext Think Tank article.
http://www.sun.com/xml/developers/resolver/
> > --
> > Cheers,
> >
> > Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [excalibur] Catalog code
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sun, Sep 23, 2001 at 08:04:02PM +1000, Peter Donald wrote:
> Hi,
>
> I just had a look at Cocoons Catalog manager code and noticed it used Suns
> code. Considering the original code is in the public domain and Suns is under
> a less than desirable license I was wondering what advantage Suns code had?
> Would there be any advantage of using arbortexts PDed code directly? I was
> thinking of adding it into Excalibur CVS and integrating it with some of our
> stuff. Anyone care to enlighten me why this may be a bad idea? ;)
I found a few minor bugs with the arbortext code (eg debug flags not getting
propagated), and one major bug (DOCTYPE doesn't work), which I mailed Norm
Walsh about. He said DOCTYPE would never work under XML due to namespace
issues, and mentioned that the Sun version had been "substantially modified",
whatever that means.
Anyway, I think it would be excellent to get *some* version of that catalog
code in under Jakarta, because it's darn useful stuff, and it doesn't have a
home. People all over the world are poking around in that code, discovering the
same bugs and limitations, and fixing them individually.
I've put an Ant-buildable version of the arbortext code at:
http://newgate.socialchange.net.au/~jeff/misc/catalog.tar.gz
--Jeff
Btw, for those who are wondering what the fuss is about, read:
http://www.arbortext.com/Think_Tank/XML_Resources/Issue_Three/issue_three.html
> --
> Cheers,
>
> Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [excalibur] Catalog code
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sun, Sep 23, 2001 at 08:04:02PM +1000, Peter Donald wrote:
> Hi,
>
> I just had a look at Cocoons Catalog manager code and noticed it used Suns
> code. Considering the original code is in the public domain and Suns is under
> a less than desirable license I was wondering what advantage Suns code had?
> Would there be any advantage of using arbortexts PDed code directly? I was
> thinking of adding it into Excalibur CVS and integrating it with some of our
> stuff. Anyone care to enlighten me why this may be a bad idea? ;)
I found a few minor bugs with the arbortext code (eg debug flags not getting
propagated), and one major bug (DOCTYPE doesn't work), which I mailed Norm
Walsh about. He said DOCTYPE would never work under XML due to namespace
issues, and mentioned that the Sun version had been "substantially modified",
whatever that means.
Anyway, I think it would be excellent to get *some* version of that catalog
code in under Jakarta, because it's darn useful stuff, and it doesn't have a
home. People all over the world are poking around in that code, discovering the
same bugs and limitations, and fixing them individually.
I've put an Ant-buildable version of the arbortext code at:
http://newgate.socialchange.net.au/~jeff/misc/catalog.tar.gz
--Jeff
Btw, for those who are wondering what the fuss is about, read:
http://www.arbortext.com/Think_Tank/XML_Resources/Issue_Three/issue_three.html
> --
> Cheers,
>
> Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org