Menu
▾
▴
rsslibj-developer — RSSLibJ Developer List
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(21) |
Mar
(9) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(3) |
Sep
(3) |
Oct
(8) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Danny A. <dan...@vi...> - 2003-03-07 11:39:39
|
[snip - all fair enough!] > Actually, this has something to do with why we chose EXML, too: because > the existing user base with Xerces was a known quantity. If we used Xerces > (or, if you like, JAXP - they're not the same, as is par for Sun's > course), we'd be binding in a version dependency. Thus, people who were > using Xerces would then be trapped into using *our* version of Xerces... > and vice versa. (True story: I know of a project that has to have TWO > versions of xerces in the same project. Lovely concept.) EXML's smaller > userbase means that deployers can drop it in without expecting the rest of > their xerces-dependent code to have any changes whatsoever. Heh, I must admit this angle hadn't occurred to me - I love it. I've been caught out by version dependency and associated problems often enough, worst of all was when I was using Crimson (in Batik) alongside Xerces (in Jena). Usually didn't have a clue which version of a class was being used. I actually think I've got 3 different versions of Xerces around as we speak (one in my dev tree, I think there's one tucked into a local Tomcat install, and another in Jena). So your arguments above have a sympathetic ear here - in fact if you've any used cars you want to sell, now would be a very good time ;-) There is another consideration, and I'd very much like to hear your thoughts - J2SE 1.4 with its XML support. At which point do you think it would make sense in a project like this to move the focus to this version? Cheers, Danny. |
|
From: Joseph O. <jo...@en...> - 2003-03-07 11:09:33
|
On Fri, 7 Mar 2003, Danny Ayers wrote:
> > > "Using JAXP to both read and write an XML document"
> > Yes, but it's also not as pretty or as elegant as EXML's.
> Prettiness and elegance would be relatively low on my priority list, but
> that's just a personal thing.
Well, yeah... agreed, but in this case, you're looking at three lines of
code versus twenty. (Slight exaggeration.) I'm a lot less interested in
doing it via JAXP when JAXP gets in the way - esp. when I have a way of
doing it that doesn't get in the way.
As I've said before, I'd love to have someone volunteer to yank the EXML
out and replace it with JAXP. I don't want the dependency either, really.
It just turned out to be such a nice API to use that going from good to
bad just doesn't feel right to me, and I use EXML a good bit, so the
impact to ME is light. I was scratching an itch, after all, and going to
JAXP is scratching an itch I don't actually have.
> > Oh, no. Actually, the namespacing in JAXP is *predeterminate* where
> > namespacing in XML is not. Consider RDF. Here's the "normal" declaration:
[snip!]
> > JAXP does not support this.
>
> The namespace prefix is really just an artifact of the serialization, so
> it'll depend on what's being used there. I'm pretty sure that whether an
> implementation extension (like those in Xerces) or a blank transform is
> used, this kind of namespace support will be available.
Yet that aspect is compensating for external serialization, not internal.
As it's an external factor, you'd still be expected to handle it.
> In JAXP, you have to search for the actual
> > name of the element, including namespace, so you have to search for
> > "rdf:RDF" and not "namespace locally referred to as rdf" and "RDF", the
> > way EXML does it. The second decl should work in EXML. It has no chance in
> > JAXP.
>
> The element is disambiguated by the combination of the namespace and the
> local name, so these will need specifying somewhere whatever you do. I
> honestly can't see much advantage in searching for one string ('rdf') over
> another ('http://www.w3.org/1999/02/22-rdf-syntax-ns#') - it'll normally be
> held in a variable either way. If you really wanted to you could write a
> couple of convenience methods.
In EXML, you declare a namespace variable (I use the misleading "rdf" for
that.) Then you would look for a tag called rdf, "RDF". It's a convenience
thing, indeed.
> The reason I have chosen JAXP (well, Xerces usually) over alternatives in
> the past is because of the existing user base, and for a lot of people it's
> a known quantity. I personally think this outweighs elegance. It took me
> half an hour to even find a page about EXML - the Eiffel parser is better
> known.
> Anyhow, there's my couple of centissimi.
Actually, this has something to do with why we chose EXML, too: because
the existing user base with Xerces was a known quantity. If we used Xerces
(or, if you like, JAXP - they're not the same, as is par for Sun's
course), we'd be binding in a version dependency. Thus, people who were
using Xerces would then be trapped into using *our* version of Xerces...
and vice versa. (True story: I know of a project that has to have TWO
versions of xerces in the same project. Lovely concept.) EXML's smaller
userbase means that deployers can drop it in without expecting the rest of
their xerces-dependent code to have any changes whatsoever.
---------------------------------------------------------
Joseph B. Ottinger jo...@en...
http://enigmastation.com IT Consultant
|
|
From: Danny A. <dan...@vi...> - 2003-03-07 01:09:34
|
> > "Using JAXP to both read and write an XML document" > > Yes, but it's also not as pretty or as elegant as EXML's. Prettiness and elegance would be relatively low on my priority list, but that's just a personal thing. > Oh, no. Actually, the namespacing in JAXP is *predeterminate* where > namespacing in XML is not. Consider RDF. Here's the "normal" declaration: > > <rdf:RDF > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:dc="http://purl.org/dc/elements/1.1/" > xmlns="http://purl.org/rss/1.0/" > > ... > > Now, consider this EQUALLY VALID declaration: > > <foo:RDF > xmlns:foo="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:dc="http://purl.org/dc/elements/1.1/" > xmlns="http://purl.org/rss/1.0/" > > > > JAXP does not support this. The namespace prefix is really just an artifact of the serialization, so it'll depend on what's being used there. I'm pretty sure that whether an implementation extension (like those in Xerces) or a blank transform is used, this kind of namespace support will be available. In JAXP, you have to search for the actual > name of the element, including namespace, so you have to search for > "rdf:RDF" and not "namespace locally referred to as rdf" and "RDF", the > way EXML does it. The second decl should work in EXML. It has no chance in > JAXP. The element is disambiguated by the combination of the namespace and the local name, so these will need specifying somewhere whatever you do. I honestly can't see much advantage in searching for one string ('rdf') over another ('http://www.w3.org/1999/02/22-rdf-syntax-ns#') - it'll normally be held in a variable either way. If you really wanted to you could write a couple of convenience methods. The reason I have chosen JAXP (well, Xerces usually) over alternatives in the past is because of the existing user base, and for a lot of people it's a known quantity. I personally think this outweighs elegance. It took me half an hour to even find a page about EXML - the Eiffel parser is better known. Anyhow, there's my couple of centissimi. Cheers, Danny. |
|
From: Joseph O. <jo...@en...> - 2003-03-06 18:03:53
|
On Thu, 6 Mar 2003, Danny Ayers wrote: > I'm not familiar with EXML (or jdom for that matter), though it's not hard > to imagine how it would be able to make things easier than JAXP. However, I > don't think JAXP's all *that* bad - specifically : > > > Porting the XML to JAXP has been considered. However, JAXP is very > > difficult to work with, compared to EXML; EXML handles generation of the > > XML for you from a DOM, for example, where JAXP requires manual > > generation. > > API implementations (such as Xerces) usually have fairly simple > serialization available, though outside of JAXP proper. It's also possible > to serialize using javax.xml.transform, see : > http://www.ibiblio.org/xml/books/xmljava/chapters/ch09s09.html > "Using JAXP to both read and write an XML document" Yes, but it's also not as pretty or as elegant as EXML's. Furthermore: > > Also, JAXP handles namespacing very poorly. > > If I remember correctly, the first release of JAXP, maybe a couple of years > ago, didn't have *any* support for namespaces, but as far as I know the > current version & implementations handle namespaces as well as one would > expect. > Oh, no. Actually, the namespacing in JAXP is *predeterminate* where namespacing in XML is not. Consider RDF. Here's the "normal" declaration: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://purl.org/rss/1.0/" > ... Now, consider this EQUALLY VALID declaration: <foo:RDF xmlns:foo="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://purl.org/rss/1.0/" > JAXP does not support this. In JAXP, you have to search for the actual name of the element, including namespace, so you have to search for "rdf:RDF" and not "namespace locally referred to as rdf" and "RDF", the way EXML does it. The second decl should work in EXML. It has no chance in JAXP. --------------------------------------------------------- Joseph B. Ottinger jo...@en... http://enigmastation.com IT Consultant |
|
From: Danny A. <dan...@vi...> - 2003-03-06 17:18:20
|
I'm not familiar with EXML (or jdom for that matter), though it's not hard to imagine how it would be able to make things easier than JAXP. However, I don't think JAXP's all *that* bad - specifically : > Porting the XML to JAXP has been considered. However, JAXP is very > difficult to work with, compared to EXML; EXML handles generation of the > XML for you from a DOM, for example, where JAXP requires manual > generation. API implementations (such as Xerces) usually have fairly simple serialization available, though outside of JAXP proper. It's also possible to serialize using javax.xml.transform, see : http://www.ibiblio.org/xml/books/xmljava/chapters/ch09s09.html "Using JAXP to both read and write an XML document" > Also, JAXP handles namespacing very poorly. If I remember correctly, the first release of JAXP, maybe a couple of years ago, didn't have *any* support for namespaces, but as far as I know the current version & implementations handle namespaces as well as one would expect. Cheers, Danny. |
|
From: Jason B. <jas...@sy...> - 2003-03-06 13:36:32
|
Hi Kate When Joe and I were discussing putting RSSLibJ together he pinned me to the wall and said "no dependencies!" :) My concern was that anyone using JDK 1.3 was not going to be able to use RSSLibJ. So our only consession was to use EXML to create the xml for us (using SAX or any part of JAXP just seemed like a bad idea). From what I can see the basic license for EXML (http://www.themindelectric.com/exml/license-EXML.html) doesn't look like they'll come looking for you. We're not using EXML+. Joe will no doubt have a more level headed answer than I will regarding the license issue. Personally I don't see anything to worry about, unless you are building an IDE or another xml parser. Kind regards Jase Bell | | | ----- Original Message ----- | From: "Kate Rhodes" <kr...@vi...> | To: <rss...@li...> | Sent: Thursday, March 06, 2003 1:24 PM | Subject: [Rsslibj-developer] licenses | | | | I read the FAQ's reasoning behind using EXML but I was wondering if any | | consideration was being made towards using something with a less | restrictive | | license. | | | | I finally got around to using RSSLibJ and it was nice, but the licensing | on | | EXML is not something I'm really comfortable with and I'd have to recode | | RSSLibJ (which I don't want to do). Also, what's the license on RSSLibJ I | | can't seem to find it anywhere. It is just public domain? | | | | -Kate | | | | | | | | ------------------------------------------------------- | | This SF.net email is sponsored by: Etnus, makers of TotalView, The | debugger | | for complex code. Debugging C/C++ programs can leave you feeling lost and | | disoriented. TotalView can help you find your way. Available on major UNIX | | and Linux platforms. Try it free. www.etnus.com | | _______________________________________________ | | Rsslibj-developer mailing list | | Rss...@li... | | https://lists.sourceforge.net/lists/listinfo/rsslibj-developer | | | | | |
|
From: Joseph O. <jo...@en...> - 2003-03-06 13:30:16
|
Hello. I've been working under the assumption that RSSLibJ was BSD- or Artistically-licensed. Formally, no decision has been made. As far as EXML is concerned, the only real restriction is that it can't be used to write an XML parser. I'm still waiting to see if it can be distributed on sourceforge, from TME. Porting the XML to JAXP has been considered. However, JAXP is very difficult to work with, compared to EXML; EXML handles generation of the XML for you from a DOM, for example, where JAXP requires manual generation. Also, JAXP handles namespacing very poorly. As a result, getting the equivalent functionality is no small amount of work. If you'd like to invest it, please do; I wouldn't have an objection to removing the EXML dependency. I just don't care to remove it myself, since I'm comfortable with EXML and it does what I need it to VERY well, moreso than the W3C's DOM API by leaps and bounds, in my opinion. On Thu, 6 Mar 2003, Kate Rhodes wrote: > I read the FAQ's reasoning behind using EXML but I was wondering if any > consideration was being made towards using something with a less restrictive > license. > > I finally got around to using RSSLibJ and it was nice, but the licensing on > EXML is not something I'm really comfortable with and I'd have to recode > RSSLibJ (which I don't want to do). Also, what's the license on RSSLibJ I > can't seem to find it anywhere. It is just public domain? > > -Kate > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Rsslibj-developer mailing list > Rss...@li... > https://lists.sourceforge.net/lists/listinfo/rsslibj-developer > --------------------------------------------------------- Joseph B. Ottinger jo...@en... http://enigmastation.com IT Consultant |
|
From: Kate R. <kr...@vi...> - 2003-03-06 13:24:35
|
I read the FAQ's reasoning behind using EXML but I was wondering if any consideration was being made towards using something with a less restrictive license. I finally got around to using RSSLibJ and it was nice, but the licensing on EXML is not something I'm really comfortable with and I'd have to recode RSSLibJ (which I don't want to do). Also, what's the license on RSSLibJ I can't seem to find it anywhere. It is just public domain? -Kate |
|
From: Joseph O. <jo...@en...> - 2003-02-25 14:35:52
|
Yeah, I saw that - and I'm applying the fix now. (I was coding it as your
email came in, oddly enough.)
Are there any other extant issues? I'd like to do a call for votes on a
1.0 release soon soon soon, like today today today if everyone agrees.
On Tue, 25 Feb 2003, Joseph Shelby wrote:
> Joseph Ottinger wrote:
> >
> > Argh, the problem lives on. I'll examine it more closely. Joe, can you
> > show me some code that duplicates the issue? I'm hoping to have a new
> > release today and I'd like it to be correct.
>
> Well, part of it was my issue -- I hadn't set "about" in my generation
> of rss, relying just on the link tags to do what I needed to do. I guess
> when writing rss100, either 1) an exception be thrown, or 2) the link value
> be used, if dealing with an Item that's missing its about property.
>
> However, it is very definitely "li" and not "item" that goes inside
> the rdf:Seq tag, so my fix is partially correct.
>
> > On Tue, 25 Feb 2003, Joseph Shelby wrote:
> >
> > > On Tue, 25 Feb 2003, Joseph Ottinger wrote:
> > >
> > > actually, 2 things are fixed:
> > > what i was getting was <item/>
> > > what i should get is <li rdf:resource="uri"/>
> > >
> > > getAbout() seems to be empty. even when i used it first with the
> > > li tag, i got <li rdf:resource=""/> or <li/> (when EXML nicely ignored
> > > an attribute with a null value).
> > >
> > > again, if the about property isn't set by something, its empty and that's
> > > causing problems. My reading of the O'Reilly article is that the uri needs
> > > to be the same as the one in the Item tag, so why not use getLink in both?.
> > >
> > > The reason is that in RDF, the order of elements technically doesn't matter,
> > > unless the elements are wrapped in an rdf:Seq container. Even if RSS 1.0
> > > were to specify that that the Item tags are in the right order, to be RDF
> > > compliant (which I need to work with existing RDF tools here @ my company),
> > > the Seq is all that matters in the order of things.
> > >
> > > Joe
> > >
> > > > Joe, the only issue with applying this patch is that I'm not sure what
> > > > it's solving. You're adding the item to the sequence, and the *main*
> > > > difference I see is that you're using the item LINK instead of the item
> > > > ABOUT data... and those should be the same reference. Am I missing
> > > > something?
> > > >
> > > > On Mon, 24 Feb 2003, Joseph Shelby wrote:
> > > >
> > > > > private void addItemsRef(Element channel, List is) {
> > > > > if(is!=null && is.size()>0) {
> > > > > Element items=channel.addElement("items");
> > > > > Element seq=items.addElement("rdf", "Seq");
> > > > > Iterator iter=is.iterator();
> > > > > while(iter.hasNext()) {
> > > > > Item item=(Item)iter.next();
> > > > > // addItem(seq, item, "resource");
> > > > > Element li = seq.addElement("li");
> > > > > li.setAttribute("rdf", "resource", item.getLink());
> > > > > }
> > > > > }
> > > > > }
> > > > >
> > > > > that now follows the rdf:Seq->li syntax described by O'Reilly's
> > > > > page
> > > > >
> > > > > http://www.oreillynet.com/pub/a/network/2000/08/25/magazine/rss_tut.html?page=3
>
>
---------------------------------------------------------
Joseph B. Ottinger jo...@en...
http://enigmastation.com IT Consultant
|
|
From: Joseph O. <jo...@en...> - 2003-02-25 13:21:02
|
Argh, the problem lives on. I'll examine it more closely. Joe, can you
show me some code that duplicates the issue? I'm hoping to have a new
release today and I'd like it to be correct.
On Tue, 25 Feb 2003, Joseph Shelby wrote:
> On Tue, 25 Feb 2003, Joseph Ottinger wrote:
>
> actually, 2 things are fixed:
> what i was getting was <item/>
> what i should get is <li rdf:resource="uri"/>
>
> getAbout() seems to be empty. even when i used it first with the
> li tag, i got <li rdf:resource=""/> or <li/> (when EXML nicely ignored
> an attribute with a null value).
>
> again, if the about property isn't set by something, its empty and that's
> causing problems. My reading of the O'Reilly article is that the uri needs
> to be the same as the one in the Item tag, so why not use getLink in both?.
>
> The reason is that in RDF, the order of elements technically doesn't matter,
> unless the elements are wrapped in an rdf:Seq container. Even if RSS 1.0
> were to specify that that the Item tags are in the right order, to be RDF
> compliant (which I need to work with existing RDF tools here @ my company),
> the Seq is all that matters in the order of things.
>
> Joe
>
> > Joe, the only issue with applying this patch is that I'm not sure what
> > it's solving. You're adding the item to the sequence, and the *main*
> > difference I see is that you're using the item LINK instead of the item
> > ABOUT data... and those should be the same reference. Am I missing
> > something?
> >
> > On Mon, 24 Feb 2003, Joseph Shelby wrote:
> >
> > > private void addItemsRef(Element channel, List is) {
> > > if(is!=null && is.size()>0) {
> > > Element items=channel.addElement("items");
> > > Element seq=items.addElement("rdf", "Seq");
> > > Iterator iter=is.iterator();
> > > while(iter.hasNext()) {
> > > Item item=(Item)iter.next();
> > > // addItem(seq, item, "resource");
> > > Element li = seq.addElement("li");
> > > li.setAttribute("rdf", "resource", item.getLink());
> > > }
> > > }
> > > }
> > >
> > > that now follows the rdf:Seq->li syntax described by O'Reilly's
> > > page
> > >
> > > http://www.oreillynet.com/pub/a/network/2000/08/25/magazine/rss_tut.html?page=3
> > >
> > > Joe
> > >
> >
> > ---------------------------------------------------------
> > Joseph B. Ottinger jo...@en...
> > http://enigmastation.com IT Consultant
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Rsslibj-developer mailing list
> > Rss...@li...
> > https://lists.sourceforge.net/lists/listinfo/rsslibj-developer
> >
>
>
---------------------------------------------------------
Joseph B. Ottinger jo...@en...
http://enigmastation.com IT Consultant
|
|
From: Joseph O. <jo...@en...> - 2003-02-25 13:19:30
|
Beauty! Then the code as it stands right now is correct.
On Tue, 25 Feb 2003, Danny Ayers wrote:
>
> > Now, the only remaining question is: "Should the <item> have its rdf:about
> > value matching the sequence's rdf:resource?" Right now, it does. I'm not
> > sure if the spec mandates it.
>
> It does:
>
> 5.3.5 <items>
> An RDF table of contents, associating the document's items [5.5] with this
> particular RSS channel. Each item's rdf:resource {item_uri} must be the same
> as the associated item element's rdf:about {item_uri}.
>
> An RDF Seq (sequence) is used to contain all the items rather than an RDF
> Bag to denote item order for rendering and reconstruction.
>
> Note that items appearing in the document but not as members of the channel
> level items sequence are likely to be discarded by RDF parsers.
>
> Syntax: <items><rdf:Seq><rdf:li resource="{item_uri}" /> ...
> </rdf:Seq></items>
> Requirement: Required
>
> http://web.resource.org/rss/1.0/spec#s5.3.5
>
---------------------------------------------------------
Joseph B. Ottinger jo...@en...
http://enigmastation.com IT Consultant
|
|
From: Joseph S. <acr...@io...> - 2003-02-25 12:57:16
|
On Tue, 25 Feb 2003, Joseph Ottinger wrote:
actually, 2 things are fixed:
what i was getting was <item/>
what i should get is <li rdf:resource="uri"/>
getAbout() seems to be empty. even when i used it first with the
li tag, i got <li rdf:resource=""/> or <li/> (when EXML nicely ignored
an attribute with a null value).
again, if the about property isn't set by something, its empty and that's
causing problems. My reading of the O'Reilly article is that the uri needs
to be the same as the one in the Item tag, so why not use getLink in both?.
The reason is that in RDF, the order of elements technically doesn't matter,
unless the elements are wrapped in an rdf:Seq container. Even if RSS 1.0
were to specify that that the Item tags are in the right order, to be RDF
compliant (which I need to work with existing RDF tools here @ my company),
the Seq is all that matters in the order of things.
Joe
> Joe, the only issue with applying this patch is that I'm not sure what
> it's solving. You're adding the item to the sequence, and the *main*
> difference I see is that you're using the item LINK instead of the item
> ABOUT data... and those should be the same reference. Am I missing
> something?
>
> On Mon, 24 Feb 2003, Joseph Shelby wrote:
>
> > private void addItemsRef(Element channel, List is) {
> > if(is!=null && is.size()>0) {
> > Element items=channel.addElement("items");
> > Element seq=items.addElement("rdf", "Seq");
> > Iterator iter=is.iterator();
> > while(iter.hasNext()) {
> > Item item=(Item)iter.next();
> > // addItem(seq, item, "resource");
> > Element li = seq.addElement("li");
> > li.setAttribute("rdf", "resource", item.getLink());
> > }
> > }
> > }
> >
> > that now follows the rdf:Seq->li syntax described by O'Reilly's
> > page
> >
> > http://www.oreillynet.com/pub/a/network/2000/08/25/magazine/rss_tut.html?page=3
> >
> > Joe
> >
>
> ---------------------------------------------------------
> Joseph B. Ottinger jo...@en...
> http://enigmastation.com IT Consultant
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Rsslibj-developer mailing list
> Rss...@li...
> https://lists.sourceforge.net/lists/listinfo/rsslibj-developer
>
--
-------------------------------------------------------------------
Joseph Shelby mailto:acr...@io...
http://www.celticdistrict.com/ http://www.io.com/~acroyear
-------------------------------------------------------------------
|
|
From: Danny A. <dan...@vi...> - 2003-02-25 12:53:48
|
> Now, the only remaining question is: "Should the <item> have its rdf:about
> value matching the sequence's rdf:resource?" Right now, it does. I'm not
> sure if the spec mandates it.
It does:
5.3.5 <items>
An RDF table of contents, associating the document's items [5.5] with this
particular RSS channel. Each item's rdf:resource {item_uri} must be the same
as the associated item element's rdf:about {item_uri}.
An RDF Seq (sequence) is used to contain all the items rather than an RDF
Bag to denote item order for rendering and reconstruction.
Note that items appearing in the document but not as members of the channel
level items sequence are likely to be discarded by RDF parsers.
Syntax: <items><rdf:Seq><rdf:li resource="{item_uri}" /> ...
</rdf:Seq></items>
Requirement: Required
http://web.resource.org/rss/1.0/spec#s5.3.5
|
|
From: Joseph O. <jo...@en...> - 2003-02-25 11:48:47
|
Argh, belay that: I won't put any change in. The writer builds the
sequence using the 'about' - and the item is stored with <link>, as the
spec shows.
Here's the relevant code to build handle the items (while building the
channel):
if(items!=null && items.size()>0) {
addItemsRef(channel, items);
Iterator iter=items.iterator();
while(iter.hasNext()) {
Item item=(Item)iter.next();
Element itemElt=addItem(root, item, "about");
addElement(itemElt, "title", item.getTitle(), true);
addElement(itemElt, "link", item.getLink(), true);
addElement(itemElt, "description", item.getDescription(),
true);
addDublinCore(itemElt, item);
}
}
And here's the code for addItem() and addItemsRef():
protected Element addItem(Element root, Item item, String resource) {
Element itemElt=null;
if(item!=null) {
itemElt=root.addElement("item");
addNSAttribute(itemElt, "rdf", resource, item.getAbout(),
false);
}
return itemElt;
}
private void addItemsRef(Element channel, List is) {
if(is!=null && is.size()>0) {
Element items=channel.addElement("items");
Element seq=items.addElement("rdf", "Seq");
Iterator iter=is.iterator();
while(iter.hasNext()) {
Item item=(Item)iter.next();
addItem(seq, item, "resource");
}
}
}
Now, the only remaining question is: "Should the <item> have its rdf:about
value matching the sequence's rdf:resource?" Right now, it does. I'm not
sure if the spec mandates it.
On Tue, 25 Feb 2003, Joseph
Ottinger wrote:
> Ahh, I see. I'll put the change in in a few hours or so.
>
> On Tue, 25 Feb 2003, Danny Ayers wrote:
>
> >
> > > Joe, the only issue with applying this patch is that I'm not sure what
> > > it's solving. You're adding the item to the sequence, and the *main*
> > > difference I see is that you're using the item LINK instead of the item
> > > ABOUT data... and those should be the same reference. Am I missing
> > > something?
> >
> > The resource in the seq should the the same as the 'about', see :
> > http://web.resource.org/rss/1.0/spec#s5.3.5
> >
> > According to the spec : "{item_uri} should be identical to the value of the
> > <link> sub-element of the <item> element, if possible.". So
> > although in most circumstances the 'about' will be the same as the <link>,
> > this isn't necessarily always the case (this was discussed a while ago on
> > rss-dev).
> >
> > (Personally I'd prefer that the specs made the <link> element optional, so
> > that self-contained items like many on blog posts were covered better, the
> > thing being described being the 'about' resource, without reference to any
> > external URL).
> >
> > Cheers,
> > DAnny.
> >
> >
> >
>
> ---------------------------------------------------------
> Joseph B. Ottinger jo...@en...
> http://enigmastation.com IT Consultant
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Rsslibj-developer mailing list
> Rss...@li...
> https://lists.sourceforge.net/lists/listinfo/rsslibj-developer
>
---------------------------------------------------------
Joseph B. Ottinger jo...@en...
http://enigmastation.com IT Consultant
|
|
From: Joseph O. <jo...@en...> - 2003-02-25 11:42:18
|
Ahh, I see. I'll put the change in in a few hours or so. On Tue, 25 Feb 2003, Danny Ayers wrote: > > > Joe, the only issue with applying this patch is that I'm not sure what > > it's solving. You're adding the item to the sequence, and the *main* > > difference I see is that you're using the item LINK instead of the item > > ABOUT data... and those should be the same reference. Am I missing > > something? > > The resource in the seq should the the same as the 'about', see : > http://web.resource.org/rss/1.0/spec#s5.3.5 > > According to the spec : "{item_uri} should be identical to the value of the > <link> sub-element of the <item> element, if possible.". So > although in most circumstances the 'about' will be the same as the <link>, > this isn't necessarily always the case (this was discussed a while ago on > rss-dev). > > (Personally I'd prefer that the specs made the <link> element optional, so > that self-contained items like many on blog posts were covered better, the > thing being described being the 'about' resource, without reference to any > external URL). > > Cheers, > DAnny. > > > --------------------------------------------------------- Joseph B. Ottinger jo...@en... http://enigmastation.com IT Consultant |
|
From: Danny A. <dan...@vi...> - 2003-02-25 10:14:19
|
> Joe, the only issue with applying this patch is that I'm not sure what > it's solving. You're adding the item to the sequence, and the *main* > difference I see is that you're using the item LINK instead of the item > ABOUT data... and those should be the same reference. Am I missing > something? The resource in the seq should the the same as the 'about', see : http://web.resource.org/rss/1.0/spec#s5.3.5 According to the spec : "{item_uri} should be identical to the value of the <link> sub-element of the <item> element, if possible.". So although in most circumstances the 'about' will be the same as the <link>, this isn't necessarily always the case (this was discussed a while ago on rss-dev). (Personally I'd prefer that the specs made the <link> element optional, so that self-contained items like many on blog posts were covered better, the thing being described being the 'about' resource, without reference to any external URL). Cheers, DAnny. |
|
From: Joseph O. <jo...@en...> - 2003-02-25 06:54:06
|
Joe, the only issue with applying this patch is that I'm not sure what
it's solving. You're adding the item to the sequence, and the *main*
difference I see is that you're using the item LINK instead of the item
ABOUT data... and those should be the same reference. Am I missing
something?
On Mon, 24 Feb 2003, Joseph Shelby wrote:
> private void addItemsRef(Element channel, List is) {
> if(is!=null && is.size()>0) {
> Element items=channel.addElement("items");
> Element seq=items.addElement("rdf", "Seq");
> Iterator iter=is.iterator();
> while(iter.hasNext()) {
> Item item=(Item)iter.next();
> // addItem(seq, item, "resource");
> Element li = seq.addElement("li");
> li.setAttribute("rdf", "resource", item.getLink());
> }
> }
> }
>
> that now follows the rdf:Seq->li syntax described by O'Reilly's
> page
>
> http://www.oreillynet.com/pub/a/network/2000/08/25/magazine/rss_tut.html?page=3
>
> Joe
>
---------------------------------------------------------
Joseph B. Ottinger jo...@en...
http://enigmastation.com IT Consultant
|
|
From: Joseph S. <acr...@io...> - 2003-02-24 23:46:45
|
private void addItemsRef(Element channel, List is) {
if(is!=null && is.size()>0) {
Element items=channel.addElement("items");
Element seq=items.addElement("rdf", "Seq");
Iterator iter=is.iterator();
while(iter.hasNext()) {
Item item=(Item)iter.next();
// addItem(seq, item, "resource");
Element li = seq.addElement("li");
li.setAttribute("rdf", "resource", item.getLink());
}
}
}
that now follows the rdf:Seq->li syntax described by O'Reilly's
page
http://www.oreillynet.com/pub/a/network/2000/08/25/magazine/rss_tut.html?page=3
Joe
--
----------------------------------------------------------------------
Joseph Shelby mailto:acr...@io...
45533 Stablemates Ct. http://www.io.com/~acroyear
Sterling, VA 20164 (703) 404-0314 | 247-7868
Software Engineer, ISX Corporation, Arlington, VA
"The people of England will permit anything...except cruelty to horses
and a rise in the price of beer." -- Return of the Musketteers (1989)
----------------------------------------------------------------------
|
|
From: Danny A. <dan...@vi...> - 2003-02-21 12:16:29
|
Hi folks, I've just a started a new project related to rsslibj (it's actually an offshoot of an existing project, but I'm building from scratch). Essentially it will be an API rather like that of rsslibj but for RSS (and other RDF) reading and writing, designed primarily for the server-side and backed by the Jena RDF API. The main part (as far as most developers are concerned) will be a set of simple interfaces for RSS channels, items etc acting as a facade to Jena. I'm only just now checking out the rsslibj source, but looking at the example on the home page the rsslibj interfaces look very much like what I have in mind. With both projects being so new, for the moment I'd rather not reuse the rsslibj interfaces but make my own as compatible as possible, ideally so that a change of back end would only need a one-line change of import statement. This could be very beneficial to both projects, as front ends could be swapped between projects at will. I've only just set things up at sourceforge and need to refactor the source a bit before uploading, but hopefully that will happen in the next week. More info at http://dannyayers.com/ideagraph-blog/archives/cat_jemblog.html Cheers, Danny. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.456 / Virus Database: 256 - Release Date: 18/02/2003 |
|
From: Joseph O. <jo...@en...> - 2003-02-14 17:46:40
|
Joe, the new version of RSSLibJ on sourceforge has both of the fixes in. BTW, I mentioned your comment on mark() to the EXML list, and Graham Glass' reply was: "good point - we could put the mark test directly into the constructor which takes a Reader. cheers, graham" BTW, I mentioned you as the one who pointed this out, so kudos will be throwin in your direction and not mine. :) On Thu, 13 Feb 2003, Joseph Shelby wrote: > Channel.getFeed yarfs if one didn't set an Image, using RDF/100 syntax. > > [java] java.lang.IllegalArgumentException: attribute rdf:resource must have data in image > [java] at com.rsslibj.writers.GenericRSSWriter.addNSAttribute(Unknown Source) > [java] at com.rsslibj.writers.defaults.rss100.addImageRef(Unknown Source) > [java] at com.rsslibj.writers.defaults.rss100.getFeed(Unknown Source) > [java] at com.rsslibj.elements.Channel.getFeed(Unknown Source) > > I was under the impression that images were optional. Channel has > "Image image = new Image()" which isn't quite right, since null > is a legit value; it should be the default. An uninitialized Image > causes problems with RDF. > > Unfortunately, there's no setImage(image/null) or removeImage() method. > > TextInput also should be null to start with, and have a clear or null > setting ability. > > Joe > --------------------------------------------------------- Joseph B. Ottinger jo...@en... http://enigmastation.com IT Consultant |
|
From: Joseph O. <jo...@en...> - 2003-02-14 00:01:34
|
Two bugs! Thank you VERY MUCH - and I'll attack these tomorrow, to get them straightened out. On Thu, 13 Feb 2003, Joseph Shelby wrote: > Channel.getFeed yarfs if one didn't set an Image, using RDF/100 syntax. > > [java] java.lang.IllegalArgumentException: attribute rdf:resource must have data in image > [java] at com.rsslibj.writers.GenericRSSWriter.addNSAttribute(Unknown Source) > [java] at com.rsslibj.writers.defaults.rss100.addImageRef(Unknown Source) > [java] at com.rsslibj.writers.defaults.rss100.getFeed(Unknown Source) > [java] at com.rsslibj.elements.Channel.getFeed(Unknown Source) > > I was under the impression that images were optional. Channel has > "Image image = new Image()" which isn't quite right, since null > is a legit value; it should be the default. An uninitialized Image > causes problems with RDF. > > Unfortunately, there's no setImage(image/null) or removeImage() method. > > TextInput also should be null to start with, and have a clear or null > setting ability. > > Joe > --------------------------------------------------------- Joseph B. Ottinger jo...@en... http://enigmastation.com IT Consultant |
|
From: Joseph S. <acr...@io...> - 2003-02-13 21:43:50
|
Channel.getFeed yarfs if one didn't set an Image, using RDF/100 syntax.
[java] java.lang.IllegalArgumentException: attribute rdf:resource must have data in image
[java] at com.rsslibj.writers.GenericRSSWriter.addNSAttribute(Unknown Source)
[java] at com.rsslibj.writers.defaults.rss100.addImageRef(Unknown Source)
[java] at com.rsslibj.writers.defaults.rss100.getFeed(Unknown Source)
[java] at com.rsslibj.elements.Channel.getFeed(Unknown Source)
I was under the impression that images were optional. Channel has
"Image image = new Image()" which isn't quite right, since null
is a legit value; it should be the default. An uninitialized Image
causes problems with RDF.
Unfortunately, there's no setImage(image/null) or removeImage() method.
TextInput also should be null to start with, and have a clear or null
setting ability.
Joe
--
----------------------------------------------------------------------
Joseph Shelby mailto:acr...@io...
45533 Stablemates Ct. http://www.io.com/~acroyear
Sterling, VA 20164 (703) 404-0314 | 247-7868
Software Engineer, ISX Corporation, Arlington, VA
"The people of England will permit anything...except cruelty to horses
and a rise in the price of beer." -- Return of the Musketteers (1989)
----------------------------------------------------------------------
|
|
From: Joseph S. <acr...@io...> - 2003-02-13 21:22:57
|
RSSReader.parseInput() :
Document d = new Document(in)
will throw an exception if using a plain FileReader, because "mark()"
isn't supported.
[java] electric.xml.ParseException: java.io.IOException: mark() not supported
[java] line 1, char 0: ...
[java] at electric.xml.NodeReader.parse(NodeReader.java:93)
[java] at electric.xml.Document.<init>(Document.java:213)
[java] at com.rsslibj.elements.RSSReader.parseInput(Unknown Source)
As you can see, this is a bug in EXML, because they should be checking.
the fix is easy
if (!in.markSupported()) in = new BufferedReader(in);
I suppose we should add that line into parseInput, but someone should
file a bug note to EXML for that. They have their own "FastBufferedReader"
they use when you pass a File into it instead of a Reader, but they
don't use it if you pass in a Reader.
Joe
--
----------------------------------------------------------------------
Joseph Shelby mailto:acr...@io...
45533 Stablemates Ct. http://www.io.com/~acroyear
Sterling, VA 20164 (703) 404-0314 | 247-7868
Software Engineer, ISX Corporation, Arlington, VA
"The people of England will permit anything...except cruelty to horses
and a rise in the price of beer." -- Return of the Musketteers (1989)
----------------------------------------------------------------------
|
|
From: Joseph O. <jo...@en...> - 2003-02-05 11:06:36
|
On Wed, 5 Feb 2003, Jason Bell wrote: > The insertItem() method makes a whole heap of sense, so I do think that > should be implemented asap. Will do. So should addItem() be renamed to appendItem()? > Item.insertItem(int position) assuming that it would throw a > NullPointerException if that position didn't exist. Um... it's an ArrayList. It's by definition sparse. Do you mean "insert item such that it appears before other items beginning at that position?" > and > > Item.insertItem() just adds to the front (as suggested in Joseph Shelby's > email). > > I'm not too sure what to think about the duplicate getItems() issue until I > have run some more real world examples. > I think cloning the list sounds less and less bright as time goes on. --------------------------------------------------------- Joseph B. Ottinger jo...@en... http://enigmastation.com IT Consultant |
|
From: Jason B. <jas...@sy...> - 2003-02-05 11:02:02
|
Hi All The insertItem() method makes a whole heap of sense, so I do think that should be implemented asap. Item.insertItem(int position) assuming that it would throw a NullPointerException if that position didn't exist. and Item.insertItem() just adds to the front (as suggested in Joseph Shelby's email). I'm not too sure what to think about the duplicate getItems() issue until I have run some more real world examples. Kind regards Jason Bell |
