|
2 proposed additions to ROME
All, I had an item to bring up as possible extension to ROME. It's possible for ROME to successfully parse an invalid feed (for example in RSS 2.0 the channel description tag is required but ROME can still parse the feed). However when using ROME to print the feed the printing will fail with an exception indicating the required tag is missing.
I'd like to add a feature to allow ROME to still print the feed, even if the original feed was invalid according to the spec. Think of it as having 2 print modes: "strict" (the default) and "easy".
For a concrete example of this see this rss feed: http://feedproxy.google.com/AbcNews_TopStories?format=xml It has the channel description tag but no value. It's be nice to be able to have ROME parse this and then be able to print it.
What do you think? Thanks, John
|
|
Re: 2 proposed additions to ROME
John, A principle behind ROME design was Postel's law: "Be liberal in what you accept, and conservative in what you send" Because of this I would recommend against it. Regardless. If you still want to this you can replace the corresponding Generator with a lenient one.
A On Fri, Jan 16, 2009 at 8:37 AM, John M <jmadden73@...> wrote:
All,
I had an item to bring up as possible extension to ROME.
It's possible for ROME to successfully parse an invalid feed (for example in RSS 2.0 the channel description tag is required but ROME can still parse the feed). However when using ROME to print the feed the printing will fail with an exception indicating the required tag is missing.
I'd like to add a feature to allow ROME to still print the feed, even if the original feed was invalid according to the spec. Think of it as having 2 print modes: "strict" (the default) and "easy".
For a concrete example of this see this rss feed: http://feedproxy.google.com/AbcNews_TopStories?format=xml
It has the channel description tag but no value. It's be nice to be able to have ROME parse this and then be able to print it.
What do you think?
Thanks,
John
|
|
Re: 2 proposed additions to ROME
In my opinion, the best solution would be for ROME to fix up the feed, where it can, when parsing it. If it finds that the description element doesn't have a value, why doesn't the parser just drop it? It does seem very counter intuitive that the generator can't generate something that the parser has successfully parsed.
I don't think being liberal in what something accepts means breaking the specifications of what its meant to produce. If the feed is invalid, the parser should make its best attempt to produce something that is valid from it, or, if it can't produce something valid, fail. There's no half way, producing something invalid is far worse than just failing outright when the feed is invalid.
Cheers, James On Fri, Jan 16, 2009 at 4:14 PM, Alejandro Abdelnur <tucu00@...> wrote:
John,
A principle behind ROME design was Postel's law: "Be liberal in what you accept, and conservative in what you send"
Because of this I would recommend against it.
Regardless. If you still want to this you can replace the corresponding Generator with a lenient one.
AOn Fri, Jan 16, 2009 at 8:37 AM, John M <jmadden73@...> wrote:
All,
I had an item to bring up as possible extension to ROME.
It's possible for ROME to successfully parse an invalid feed (for example in RSS 2.0 the channel description tag is required but ROME can still parse the feed). However when using ROME to print the feed the printing will fail with an exception indicating the required tag is missing.
I'd like to add a feature to allow ROME to still print the feed, even if the original feed was invalid according to the spec. Think of it as having 2 print modes: "strict" (the default) and "easy".
For a concrete example of this see this rss feed: http://feedproxy.google.com/AbcNews_TopStories?format=xml
It has the channel description tag but no value. It's be nice to be able to have ROME parse this and then be able to print it.
What do you think?
Thanks,
John
|
|
RE: 2 proposed additions to ROME
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I don’t quite understand what you are saying here.
There are some cases where ROME can parse a feed which is technically incorrect (== being liberal in what it accepts).
ROME will (should) never produce a feed which is invalid (== being strict in what we send)
That’s what we do at the moment – as John M noted, you can parse a RSS 2.0 feed with a missing channel description. However, you cannot produce the same thing
– you must correct it and make it spec compliant before the feed will be generated.
Nick
From: James Roper [mailto:jroper2@...]
Sent: Friday, 16 January 2009 5:25 PM
To: dev@...
Subject: Re: 2 proposed additions to ROME
In my opinion, the best solution would be for ROME to fix up the feed, where it can, when parsing it. If it finds that the description element doesn't have a value, why doesn't the parser just drop it? It
does seem very counter intuitive that the generator can't generate something that the parser has successfully parsed.
I don't think being liberal in what something accepts means breaking the specifications of what its meant to produce. If the feed is invalid, the parser should make its best attempt to produce something that is valid from it, or, if it can't produce something
valid, fail. There's no half way, producing something invalid is far worse than just failing outright when the feed is invalid.
Cheers,
James
On Fri, Jan 16, 2009 at 4:14 PM, Alejandro Abdelnur <tucu00@...> wrote:
John,
A principle behind ROME design was Postel's law: "Be liberal in what you accept, and conservative in what you send"
Because of this I would recommend against it.
Regardless. If you still want to this you can replace the corresponding Generator with a lenient one.
A
On Fri, Jan 16, 2009 at 8:37 AM, John M <jmadden73@...> wrote:
All,
I had an item to bring up as possible extension to ROME.
It's possible for ROME to successfully parse an invalid feed (for example in RSS 2.0 the channel description tag is required but ROME can still parse the feed). However when using ROME to print the feed the printing will fail with an exception indicating
the required tag is missing.
I'd like to add a feature to allow ROME to still print the feed, even if the original feed was invalid according to the spec. Think of it as having 2 print modes: "strict" (the default) and "easy".
For a concrete example of this see this rss feed:
http://feedproxy.google.com/AbcNews_TopStories?format=xml
It has the channel description tag but no value. It's be nice to be able to have ROME parse this and then be able to print it.
What do you think?
Thanks,
John
IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the
sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not
necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss,
damage or consequence caused directly or indirectly by this email.
|
|
Re: 2 proposed additions to ROME
Can we have ROME automatically fix the feed? For example, during the feed generation for printing there are a series of checks the ROME generators perform to make sure the generated feed conforms to the spec. How about having the generators "fix' malformed feeds by inserting an empty string, the tag name, etc. in the location where the feed is broken rather than failing with an error. That would be a "lenient" mode ROME could be put into by setting a property in the rome.properties file.
This will still make the rule of "liberal with ingest, conservative with output" hold true. Thanks, -John M. On Sun, Jan 18, 2009 at 5:18 PM, Nick Lothian <nlothian@...> wrote:
I don't quite understand what you are saying here.
There are some cases where ROME can parse a feed which is technically incorrect (== being liberal in what it accepts).
ROME will (should) never produce a feed which is invalid (== being strict in what we send)
That's what we do at the moment – as John M noted, you can parse a RSS 2.0 feed with a missing channel description. However, you cannot produce the same thing
– you must correct it and make it spec compliant before the feed will be generated.
Nick
From: James Roper [mailto:jroper2@...]
Sent: Friday, 16 January 2009 5:25 PM
To: dev@...
Subject: Re: 2 proposed additions to ROME
In my opinion, the best solution would be for ROME to fix up the feed, where it can, when parsing it. If it finds that the description element doesn't have a value, why doesn't the parser just drop it? It
does seem very counter intuitive that the generator can't generate something that the parser has successfully parsed.
I don't think being liberal in what something accepts means breaking the specifications of what its meant to produce. If the feed is invalid, the parser should make its best attempt to produce something that is valid from it, or, if it can't produce something
valid, fail. There's no half way, producing something invalid is far worse than just failing outright when the feed is invalid.
Cheers,
James
On Fri, Jan 16, 2009 at 4:14 PM, Alejandro Abdelnur <tucu00@...> wrote:
John,
A principle behind ROME design was Postel's law: "Be liberal in what you accept, and conservative in what you send"
Because of this I would recommend against it.
Regardless. If you still want to this you can replace the corresponding Generator with a lenient one.
A
On Fri, Jan 16, 2009 at 8:37 AM, John M <jmadden73@...> wrote:
All,
I had an item to bring up as possible extension to ROME.
It's possible for ROME to successfully parse an invalid feed (for example in RSS 2.0 the channel description tag is required but ROME can still parse the feed). However when using ROME to print the feed the printing will fail with an exception indicating
the required tag is missing.
I'd like to add a feature to allow ROME to still print the feed, even if the original feed was invalid according to the spec. Think of it as having 2 print modes: "strict" (the default) and "easy".
For a concrete example of this see this rss feed:
http://feedproxy.google.com/AbcNews_TopStories?format=xml
It has the channel description tag but no value. It's be nice to be able to have ROME parse this and then be able to print it.
What do you think?
Thanks,
John
IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the
sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not
necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss,
damage or consequence caused directly or indirectly by this email.
|
|
Re: 2 proposed additions to ROME
automatically how? I think this depends on what you are trying to do. You could have a helper class that traverses the entries of the feed doing the check and corrections and after you call this logic you output the feed.
A On Tue, Jan 20, 2009 at 8:38 AM, John M <jmadden73@...> wrote:
Can we have ROME automatically fix the feed? For example, during the feed generation for printing there are a series of checks the ROME generators perform to make sure the generated feed conforms to the spec.
How about having the generators "fix' malformed feeds by inserting an empty string, the tag name, etc. in the location where the feed is broken rather than failing with an error. That would be a "lenient" mode ROME could be put into by setting a property in the rome.properties file.
This will still make the rule of "liberal with ingest, conservative with output" hold true.
Thanks,
-John M.
On Sun, Jan 18, 2009 at 5:18 PM, Nick Lothian <nlothian@...> wrote:
I don't quite understand what you are saying here.
There are some cases where ROME can parse a feed which is technically incorrect (== being liberal in what it accepts).
ROME will (should) never produce a feed which is invalid (== being strict in what we send)
That's what we do at the moment – as John M noted, you can parse a RSS 2.0 feed with a missing channel description. However, you cannot produce the same thing
– you must correct it and make it spec compliant before the feed will be generated.
Nick
From: James Roper [mailto:jroper2@...]
Sent: Friday, 16 January 2009 5:25 PM
To: dev@...
Subject: Re: 2 proposed additions to ROME
In my opinion, the best solution would be for ROME to fix up the feed, where it can, when parsing it. If it finds that the description element doesn't have a value, why doesn't the parser just drop it? It
does seem very counter intuitive that the generator can't generate something that the parser has successfully parsed.
I don't think being liberal in what something accepts means breaking the specifications of what its meant to produce. If the feed is invalid, the parser should make its best attempt to produce something that is valid from it, or, if it can't produce something
valid, fail. There's no half way, producing something invalid is far worse than just failing outright when the feed is invalid.
Cheers,
James
On Fri, Jan 16, 2009 at 4:14 PM, Alejandro Abdelnur <tucu00@...> wrote:
John,
A principle behind ROME design was Postel's law: "Be liberal in what you accept, and conservative in what you send"
Because of this I would recommend against it.
Regardless. If you still want to this you can replace the corresponding Generator with a lenient one.
A
On Fri, Jan 16, 2009 at 8:37 AM, John M <jmadden73@...> wrote:
All,
I had an item to bring up as possible extension to ROME.
It's possible for ROME to successfully parse an invalid feed (for example in RSS 2.0 the channel description tag is required but ROME can still parse the feed). However when using ROME to print the feed the printing will fail with an exception indicating
the required tag is missing.
I'd like to add a feature to allow ROME to still print the feed, even if the original feed was invalid according to the spec. Think of it as having 2 print modes: "strict" (the default) and "easy".
For a concrete example of this see this rss feed:
http://feedproxy.google.com/AbcNews_TopStories?format=xml
It has the channel description tag but no value. It's be nice to be able to have ROME parse this and then be able to print it.
What do you think?
Thanks,
John
IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the
sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not
necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss,
damage or consequence caused directly or indirectly by this email.
|
|
Re: 2 proposed additions to ROME
I think it's a matter of the parser making the right trivial decisions
as it parses. Using the example above, one thing the parser should
do, is when it parses the description tag, if it has no value, insert
a default value, for example "No description found." This makes the
feed internally valid, that is, the SyndFeed object will pass
validation when it gets generated, and it means that applications
using ROME don't need to do their own checks for things that are
supposed to be guaranteed by the RSS spec - this is ROME's job, even
if it is being liberal about what it accepts.
-James
On Tue, Jan 20, 2009 at 3:36 PM, Alejandro Abdelnur < tucu00@...> wrote:
> automatically how? I think this depends on what you are trying to do.
>
> You could have a helper class that traverses the entries of the feed doing
> the check and corrections and after you call this logic you output the feed.
>
> A
>
> On Tue, Jan 20, 2009 at 8:38 AM, John M < jmadden73@...> wrote:
>>
>> Can we have ROME automatically fix the feed? For example, during the feed
>> generation for printing there are a series of checks the ROME generators
>> perform to make sure the generated feed conforms to the spec.
>>
>> How about having the generators "fix' malformed feeds by inserting an
>> empty string, the tag name, etc. in the location where the feed is broken
>> rather than failing with an error. That would be a "lenient" mode ROME
>> could be put into by setting a property in the rome.properties file.
>>
>> This will still make the rule of "liberal with ingest, conservative with
>> output" hold true.
>>
>> Thanks,
>> -John M.
>>
>> On Sun, Jan 18, 2009 at 5:18 PM, Nick Lothian
>> < nlothian@...> wrote:
>>>
>>> I don't quite understand what you are saying here.
>>>
>>>
>>>
>>> There are some cases where ROME can parse a feed which is technically
>>> incorrect (== being liberal in what it accepts).
>>>
>>> ROME will (should) never produce a feed which is invalid (== being strict
>>> in what we send)
>>>
>>>
>>>
>>> That's what we do at the moment – as John M noted, you can parse a RSS
>>> 2.0 feed with a missing channel description. However, you cannot produce the
>>> same thing – you must correct it and make it spec compliant before the feed
>>> will be generated.
>>>
>>>
>>>
>>> Nick
>>>
>>>
>>>
>>>
>>>
>>> From: James Roper [mailto: jroper2@...]
>>> Sent: Friday, 16 January 2009 5:25 PM
>>> To: dev@...
>>> Subject: Re: 2 proposed additions to ROME
>>>
>>>
>>>
>>> In my opinion, the best solution would be for ROME to fix up the feed,
>>> where it can, when parsing it. If it finds that the description element
>>> doesn't have a value, why doesn't the parser just drop it? It does seem
>>> very counter intuitive that the generator can't generate something that the
>>> parser has successfully parsed.
>>>
>>> I don't think being liberal in what something accepts means breaking the
>>> specifications of what its meant to produce. If the feed is invalid, the
>>> parser should make its best attempt to produce something that is valid from
>>> it, or, if it can't produce something valid, fail. There's no half way,
>>> producing something invalid is far worse than just failing outright when the
>>> feed is invalid.
>>>
>>> Cheers,
>>>
>>> James
>>>
>>> On Fri, Jan 16, 2009 at 4:14 PM, Alejandro Abdelnur < tucu00@...>
>>> wrote:
>>>
>>> John,
>>>
>>> A principle behind ROME design was Postel's law: "Be liberal in what you
>>> accept, and conservative in what you send"
>>>
>>> Because of this I would recommend against it.
>>>
>>> Regardless. If you still want to this you can replace the corresponding
>>> Generator with a lenient one.
>>>
>>> A
>>>
>>>
>>>
>>> On Fri, Jan 16, 2009 at 8:37 AM, John M < jmadden73@...> wrote:
>>>
>>> All,
>>> I had an item to bring up as possible extension to ROME.
>>>
>>> It's possible for ROME to successfully parse an invalid feed (for
>>> example in RSS 2.0 the channel description tag is required but ROME can
>>> still parse the feed). However when using ROME to print the feed the
>>> printing will fail with an exception indicating the required tag is missing.
>>>
>>> I'd like to add a feature to allow ROME to still print the feed, even
>>> if the original feed was invalid according to the spec. Think of it as
>>> having 2 print modes: "strict" (the default) and "easy".
>>>
>>> For a concrete example of this see this rss feed:
>>> http://feedproxy.google.com/AbcNews_TopStories?format=xml>>> It has the channel description tag but no value. It's be nice to be
>>> able to have ROME parse this and then be able to print it.
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> IMPORTANT: This e-mail, including any attachments, may contain private or
>>> confidential information. If you think you may not be the intended
>>> recipient, or if you have received this e-mail in error, please contact the
>>> sender immediately and delete all copies of this e-mail. If you are not the
>>> intended recipient, you must not reproduce any part of this e-mail or
>>> disclose its contents to any other party. This email represents the views of
>>> the individual sender, which do not necessarily reflect those of
>>> Education.au except where the sender expressly states otherwise. It is your
>>> responsibility to scan this email and any files transmitted with it for
>>> viruses or any other defects. education.au limited will not be liable for
>>> any loss, damage or consequence caused directly or indirectly by this email.
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
Re: 2 proposed additions to ROME
I don't agree on populating things with 'not found' values by default. But definitely is something you can do. Even in the parser, if you plugin your own parser. A
On Tue, Jan 20, 2009 at 10:26 AM, James Roper <jroper2@...> wrote:
I think it's a matter of the parser making the right trivial decisions
as it parses. Using the example above, one thing the parser should
do, is when it parses the description tag, if it has no value, insert
a default value, for example "No description found." This makes the
feed internally valid, that is, the SyndFeed object will pass
validation when it gets generated, and it means that applications
using ROME don't need to do their own checks for things that are
supposed to be guaranteed by the RSS spec - this is ROME's job, even
if it is being liberal about what it accepts.
-James
On Tue, Jan 20, 2009 at 3:36 PM, Alejandro Abdelnur < tucu00@...> wrote:
> automatically how? I think this depends on what you are trying to do.
>
> You could have a helper class that traverses the entries of the feed doing
> the check and corrections and after you call this logic you output the feed.
>
> A
>
> On Tue, Jan 20, 2009 at 8:38 AM, John M < jmadden73@...> wrote:
>>
>> Can we have ROME automatically fix the feed? For example, during the feed
>> generation for printing there are a series of checks the ROME generators
>> perform to make sure the generated feed conforms to the spec.
>>
>> How about having the generators "fix' malformed feeds by inserting an
>> empty string, the tag name, etc. in the location where the feed is broken
>> rather than failing with an error. That would be a "lenient" mode ROME
>> could be put into by setting a property in the rome.properties file.
>>
>> This will still make the rule of "liberal with ingest, conservative with
>> output" hold true.
>>
>> Thanks,
>> -John M.
>>
>> On Sun, Jan 18, 2009 at 5:18 PM, Nick Lothian
>> < nlothian@...> wrote:
>>>
>>> I don't quite understand what you are saying here.
>>>
>>>
>>>
>>> There are some cases where ROME can parse a feed which is technically
>>> incorrect (== being liberal in what it accepts).
>>>
>>> ROME will (should) never produce a feed which is invalid (== being strict
>>> in what we send)
>>>
>>>
>>>
>>> That's what we do at the moment – as John M noted, you can parse a RSS
>>> 2.0 feed with a missing channel description. However, you cannot produce the
>>> same thing – you must correct it and make it spec compliant before the feed
>>> will be generated.
>>>
>>>
>>>
>>> Nick
>>>
>>>
>>>
>>>
>>>
>>> From: James Roper [mailto: jroper2@...]
>>> Sent: Friday, 16 January 2009 5:25 PM
>>> To: dev@...
>>> Subject: Re: 2 proposed additions to ROME
>>>
>>>
>>>
>>> In my opinion, the best solution would be for ROME to fix up the feed,
>>> where it can, when parsing it. If it finds that the description element
>>> doesn't have a value, why doesn't the parser just drop it? It does seem
>>> very counter intuitive that the generator can't generate something that the
>>> parser has successfully parsed.
>>>
>>> I don't think being liberal in what something accepts means breaking the
>>> specifications of what its meant to produce. If the feed is invalid, the
>>> parser should make its best attempt to produce something that is valid from
>>> it, or, if it can't produce something valid, fail. There's no half way,
>>> producing something invalid is far worse than just failing outright when the
>>> feed is invalid.
>>>
>>> Cheers,
>>>
>>> James
>>>
>>> On Fri, Jan 16, 2009 at 4:14 PM, Alejandro Abdelnur < tucu00@...>
>>> wrote:
>>>
>>> John,
>>>
>>> A principle behind ROME design was Postel's law: "Be liberal in what you
>>> accept, and conservative in what you send"
>>>
>>> Because of this I would recommend against it.
>>>
>>> Regardless. If you still want to this you can replace the corresponding
>>> Generator with a lenient one.
>>>
>>> A
>>>
>>>
>>>
>>> On Fri, Jan 16, 2009 at 8:37 AM, John M < jmadden73@...> wrote:
>>>
>>> All,
>>> I had an item to bring up as possible extension to ROME.
>>>
>>> It's possible for ROME to successfully parse an invalid feed (for
>>> example in RSS 2.0 the channel description tag is required but ROME can
>>> still parse the feed). However when using ROME to print the feed the
>>> printing will fail with an exception indicating the required tag is missing.
>>>
>>> I'd like to add a feature to allow ROME to still print the feed, even
>>> if the original feed was invalid according to the spec. Think of it as
>>> having 2 print modes: "strict" (the default) and "easy".
>>>
>>> For a concrete example of this see this rss feed:
>>> http://feedproxy.google.com/AbcNews_TopStories?format=xml
>>> It has the channel description tag but no value. It's be nice to be
>>> able to have ROME parse this and then be able to print it.
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> IMPORTANT: This e-mail, including any attachments, may contain private or
>>> confidential information. If you think you may not be the intended
>>> recipient, or if you have received this e-mail in error, please contact the
>>> sender immediately and delete all copies of this e-mail. If you are not the
>>> intended recipient, you must not reproduce any part of this e-mail or
>>> disclose its contents to any other party. This email represents the views of
>>> the individual sender, which do not necessarily reflect those of
>>> Education.au except where the sender expressly states otherwise. It is your
>>> responsibility to scan this email and any files transmitted with it for
>>> viruses or any other defects. education.au limited will not be liable for
>>> any loss, damage or consequence caused directly or indirectly by this email.
>>
>
>
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
RE: 2 proposed additions to ROME
I suspect that - from the users point of view - a message like "No description found" is likely to be a bigger problem than ROME erroring.
At least when ROME errors the software developer is likely to see the problem. If ROME inserted default messages like that then the first the developer may know of it is when it is reported by a user.
Fail-fast is a good principle.
I can see the argument for some kind of default generator, but I'd tend towards zero-length strings being the default for string values. I'm not sure what we'd do for dates, though.
I think it's worth pointing out that users can already implement this themselves by creating a custom Generator and changing rome.properties. (They could also send in a patch!)
Nick
-----Original Message-----
From: James Roper [mailto: jroper2@...]
Sent: Tuesday, 20 January 2009 3:26 PM
To: dev@...
Subject: Re: 2 proposed additions to ROME
I think it's a matter of the parser making the right trivial decisions
as it parses. Using the example above, one thing the parser should
do, is when it parses the description tag, if it has no value, insert
a default value, for example "No description found." This makes the
feed internally valid, that is, the SyndFeed object will pass
validation when it gets generated, and it means that applications
using ROME don't need to do their own checks for things that are
supposed to be guaranteed by the RSS spec - this is ROME's job, even
if it is being liberal about what it accepts.
-James
On Tue, Jan 20, 2009 at 3:36 PM, Alejandro Abdelnur < tucu00@...> wrote:
> automatically how? I think this depends on what you are trying to do.
>
> You could have a helper class that traverses the entries of the feed doing
> the check and corrections and after you call this logic you output the feed.
>
> A
>
> On Tue, Jan 20, 2009 at 8:38 AM, John M < jmadden73@...> wrote:
>>
>> Can we have ROME automatically fix the feed? For example, during the feed
>> generation for printing there are a series of checks the ROME generators
>> perform to make sure the generated feed conforms to the spec.
>>
>> How about having the generators "fix' malformed feeds by inserting an
>> empty string, the tag name, etc. in the location where the feed is broken
>> rather than failing with an error. That would be a "lenient" mode ROME
>> could be put into by setting a property in the rome.properties file.
>>
>> This will still make the rule of "liberal with ingest, conservative with
>> output" hold true.
>>
>> Thanks,
>> -John M.
>>
>> On Sun, Jan 18, 2009 at 5:18 PM, Nick Lothian
>> < nlothian@...> wrote:
>>>
>>> I don't quite understand what you are saying here.
>>>
>>>
>>>
>>> There are some cases where ROME can parse a feed which is technically
>>> incorrect (== being liberal in what it accepts).
>>>
>>> ROME will (should) never produce a feed which is invalid (== being strict
>>> in what we send)
>>>
>>>
>>>
>>> That's what we do at the moment - as John M noted, you can parse a RSS
>>> 2.0 feed with a missing channel description. However, you cannot produce the
>>> same thing - you must correct it and make it spec compliant before the feed
>>> will be generated.
>>>
>>>
>>>
>>> Nick
>>>
>>>
>>>
>>>
>>>
>>> From: James Roper [mailto: jroper2@...]
>>> Sent: Friday, 16 January 2009 5:25 PM
>>> To: dev@...
>>> Subject: Re: 2 proposed additions to ROME
>>>
>>>
>>>
>>> In my opinion, the best solution would be for ROME to fix up the feed,
>>> where it can, when parsing it. If it finds that the description element
>>> doesn't have a value, why doesn't the parser just drop it? It does seem
>>> very counter intuitive that the generator can't generate something that the
>>> parser has successfully parsed.
>>>
>>> I don't think being liberal in what something accepts means breaking the
>>> specifications of what its meant to produce. If the feed is invalid, the
>>> parser should make its best attempt to produce something that is valid from
>>> it, or, if it can't produce something valid, fail. There's no half way,
>>> producing something invalid is far worse than just failing outright when the
>>> feed is invalid.
>>>
>>> Cheers,
>>>
>>> James
>>>
>>> On Fri, Jan 16, 2009 at 4:14 PM, Alejandro Abdelnur < tucu00@...>
>>> wrote:
>>>
>>> John,
>>>
>>> A principle behind ROME design was Postel's law: "Be liberal in what you
>>> accept, and conservative in what you send"
>>>
>>> Because of this I would recommend against it.
>>>
>>> Regardless. If you still want to this you can replace the corresponding
>>> Generator with a lenient one.
>>>
>>> A
>>>
>>>
>>>
>>> On Fri, Jan 16, 2009 at 8:37 AM, John M < jmadden73@...> wrote:
>>>
>>> All,
>>> I had an item to bring up as possible extension to ROME.
>>>
>>> It's possible for ROME to successfully parse an invalid feed (for
>>> example in RSS 2.0 the channel description tag is required but ROME can
>>> still parse the feed). However when using ROME to print the feed the
>>> printing will fail with an exception indicating the required tag is missing.
>>>
>>> I'd like to add a feature to allow ROME to still print the feed, even
>>> if the original feed was invalid according to the spec. Think of it as
>>> having 2 print modes: "strict" (the default) and "easy".
>>>
>>> For a concrete example of this see this rss feed:
>>> http://feedproxy.google.com/AbcNews_TopStories?format=xml>>> It has the channel description tag but no value. It's be nice to be
>>> able to have ROME parse this and then be able to print it.
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> IMPORTANT: This e-mail, including any attachments, may contain private or
>>> confidential information. If you think you may not be the intended
>>> recipient, or if you have received this e-mail in error, please contact the
>>> sender immediately and delete all copies of this e-mail. If you are not the
>>> intended recipient, you must not reproduce any part of this e-mail or
>>> disclose its contents to any other party. This email represents the views of
>>> the individual sender, which do not necessarily reflect those of
>>> Education.au except where the sender expressly states otherwise. It is your
>>> responsibility to scan this email and any files transmitted with it for
>>> viruses or any other defects. education.au limited will not be liable for
>>> any loss, damage or consequence caused directly or indirectly by this email.
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
Re: 2 proposed additions to ROME
I think the custom generator, with some documentation about how to use it, might be a useful addition. I'll volunteer to write it since I started this thread :-) I'll get it done soon & submit it as a patch for possible addition to the baseline.
Thanks! This was a very fruitful discussion! Thanks, John M On Tue, Jan 20, 2009 at 12:06 AM, Nick Lothian <nlothian@...> wrote:
I suspect that - from the users point of view - a message like "No description found" is likely to be a bigger problem than ROME erroring.
At least when ROME errors the software developer is likely to see the problem. If ROME inserted default messages like that then the first the developer may know of it is when it is reported by a user.
Fail-fast is a good principle.
I can see the argument for some kind of default generator, but I'd tend towards zero-length strings being the default for string values. I'm not sure what we'd do for dates, though.
I think it's worth pointing out that users can already implement this themselves by creating a custom Generator and changing rome.properties. (They could also send in a patch!)
Nick
-----Original Message-----
From: James Roper [mailto: jroper2@...]
Sent: Tuesday, 20 January 2009 3:26 PM
To: dev@...
Subject: Re: 2 proposed additions to ROME
I think it's a matter of the parser making the right trivial decisions
as it parses. Using the example above, one thing the parser should
do, is when it parses the description tag, if it has no value, insert
a default value, for example "No description found." This makes the
feed internally valid, that is, the SyndFeed object will pass
validation when it gets generated, and it means that applications
using ROME don't need to do their own checks for things that are
supposed to be guaranteed by the RSS spec - this is ROME's job, even
if it is being liberal about what it accepts.
-James
On Tue, Jan 20, 2009 at 3:36 PM, Alejandro Abdelnur < tucu00@...> wrote:
> automatically how? I think this depends on what you are trying to do.
>
> You could have a helper class that traverses the entries of the feed doing
> the check and corrections and after you call this logic you output the feed.
>
> A
>
> On Tue, Jan 20, 2009 at 8:38 AM, John M < jmadden73@...> wrote:
>>
>> Can we have ROME automatically fix the feed? For example, during the feed
>> generation for printing there are a series of checks the ROME generators
>> perform to make sure the generated feed conforms to the spec.
>>
>> How about having the generators "fix' malformed feeds by inserting an
>> empty string, the tag name, etc. in the location where the feed is broken
>> rather than failing with an error. That would be a "lenient" mode ROME
>> could be put into by setting a property in the rome.properties file.
>>
>> This will still make the rule of "liberal with ingest, conservative with
>> output" hold true.
>>
>> Thanks,
>> -John M.
>>
>> On Sun, Jan 18, 2009 at 5:18 PM, Nick Lothian
>> < nlothian@...> wrote:
>>>
>>> I don't quite understand what you are saying here.
>>>
>>>
>>>
>>> There are some cases where ROME can parse a feed which is technically
>>> incorrect (== being liberal in what it accepts).
>>>
>>> ROME will (should) never produce a feed which is invalid (== being strict
>>> in what we send)
>>>
>>>
>>>
>>> That's what we do at the moment - as John M noted, you can parse a RSS
>>> 2.0 feed with a missing channel description. However, you cannot produce the
>>> same thing - you must correct it and make it spec compliant before the feed
>>> will be generated.
>>>
>>>
>>>
>>> Nick
>>>
>>>
>>>
>>>
>>>
>>> From: James Roper [mailto: jroper2@...]
>>> Sent: Friday, 16 January 2009 5:25 PM
>>> To: dev@...
>>> Subject: Re: 2 proposed additions to ROME
>>>
>>>
>>>
>>> In my opinion, the best solution would be for ROME to fix up the feed,
>>> where it can, when parsing it. If it finds that the description element
>>> doesn't have a value, why doesn't the parser just drop it? It does seem
>>> very counter intuitive that the generator can't generate something that the
>>> parser has successfully parsed.
>>>
>>> I don't think being liberal in what something accepts means breaking the
>>> specifications of what its meant to produce. If the feed is invalid, the
>>> parser should make its best attempt to produce something that is valid from
>>> it, or, if it can't produce something valid, fail. There's no half way,
>>> producing something invalid is far worse than just failing outright when the
>>> feed is invalid.
>>>
>>> Cheers,
>>>
>>> James
>>>
>>> On Fri, Jan 16, 2009 at 4:14 PM, Alejandro Abdelnur < tucu00@...>
>>> wrote:
>>>
>>> John,
>>>
>>> A principle behind ROME design was Postel's law: "Be liberal in what you
>>> accept, and conservative in what you send"
>>>
>>> Because of this I would recommend against it.
>>>
>>> Regardless. If you still want to this you can replace the corresponding
>>> Generator with a lenient one.
>>>
>>> A
>>>
>>>
>>>
>>> On Fri, Jan 16, 2009 at 8:37 AM, John M < jmadden73@...> wrote:
>>>
>>> All,
>>> I had an item to bring up as possible extension to ROME.
>>>
>>> It's possible for ROME to successfully parse an invalid feed (for
>>> example in RSS 2.0 the channel description tag is required but ROME can
>>> still parse the feed). However when using ROME to print the feed the
>>> printing will fail with an exception indicating the required tag is missing.
>>>
>>> I'd like to add a feature to allow ROME to still print the feed, even
>>> if the original feed was invalid according to the spec. Think of it as
>>> having 2 print modes: "strict" (the default) and "easy".
>>>
>>> For a concrete example of this see this rss feed:
>>> http://feedproxy.google.com/AbcNews_TopStories?format=xml
>>> It has the channel description tag but no value. It's be nice to be
>>> able to have ROME parse this and then be able to print it.
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> IMPORTANT: This e-mail, including any attachments, may contain private or
>>> confidential information. If you think you may not be the intended
>>> recipient, or if you have received this e-mail in error, please contact the
>>> sender immediately and delete all copies of this e-mail. If you are not the
>>> intended recipient, you must not reproduce any part of this e-mail or
>>> disclose its contents to any other party. This email represents the views of
>>> the individual sender, which do not necessarily reflect those of
>>> Education.au except where the sender expressly states otherwise. It is your
>>> responsibility to scan this email and any files transmitted with it for
>>> viruses or any other defects. education.au limited will not be liable for
>>> any loss, damage or consequence caused directly or indirectly by this email.
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
Re: 2 proposed additions to ROME
Okay, Attached is a proposed 'lenient' generator. However, I was working on writing a test case (to fit into the current Junit testing architecture) and was unable to come up with a good way to test. The only way I could think of would be to have a rome.properties in the same package where my test was -- but won't this potentially impact other tests since the generators get loaded when the WireFeedOutput class gets loaded (and only gets done once)?
It looks like the plugin design was intented to be initialized only once and never modified -- no changes to generators after the code is running. -John M On Tue, Jan 20, 2009 at 3:06 PM, John M <jmadden73@...> wrote:
I think the custom generator, with some documentation about how to use it, might be a useful addition. I'll volunteer to write it since I started this thread :-)
I'll get it done soon & submit it as a patch for possible addition to the baseline.
Thanks! This was a very fruitful discussion!
Thanks,
John MOn Tue, Jan 20, 2009 at 12:06 AM, Nick Lothian <nlothian@...> wrote:
I suspect that - from the users point of view - a message like "No description found" is likely to be a bigger problem than ROME erroring.
At least when ROME errors the software developer is likely to see the problem. If ROME inserted default messages like that then the first the developer may know of it is when it is reported by a user.
Fail-fast is a good principle.
I can see the argument for some kind of default generator, but I'd tend towards zero-length strings being the default for string values. I'm not sure what we'd do for dates, though.
I think it's worth pointing out that users can already implement this themselves by creating a custom Generator and changing rome.properties. (They could also send in a patch!)
Nick
-----Original Message-----
From: James Roper [mailto: jroper2@...]
Sent: Tuesday, 20 January 2009 3:26 PM
To: dev@...
Subject: Re: 2 proposed additions to ROME
I think it's a matter of the parser making the right trivial decisions
as it parses. Using the example above, one thing the parser should
do, is when it parses the description tag, if it has no value, insert
a default value, for example "No description found." This makes the
feed internally valid, that is, the SyndFeed object will pass
validation when it gets generated, and it means that applications
using ROME don't need to do their own checks for things that are
supposed to be guaranteed by the RSS spec - this is ROME's job, even
if it is being liberal about what it accepts.
-James
On Tue, Jan 20, 2009 at 3:36 PM, Alejandro Abdelnur < tucu00@...> wrote:
> automatically how? I think this depends on what you are trying to do.
>
> You could have a helper class that traverses the entries of the feed doing
> the check and corrections and after you call this logic you output the feed.
>
> A
>
> On Tue, Jan 20, 2009 at 8:38 AM, John M < jmadden73@...> wrote:
>>
>> Can we have ROME automatically fix the feed? For example, during the feed
>> generation for printing there are a series of checks the ROME generators
>> perform to make sure the generated feed conforms to the spec.
>>
>> How about having the generators "fix' malformed feeds by inserting an
>> empty string, the tag name, etc. in the location where the feed is broken
>> rather than failing with an error. That would be a "lenient" mode ROME
>> could be put into by setting a property in the rome.properties file.
>>
>> This will still make the rule of "liberal with ingest, conservative with
>> output" hold true.
>>
>> Thanks,
>> -John M.
>>
>> On Sun, Jan 18, 2009 at 5:18 PM, Nick Lothian
>> < nlothian@...> wrote:
>>>
>>> I don't quite understand what you are saying here.
>>>
>>>
>>>
>>> There are some cases where ROME can parse a feed which is technically
>>> incorrect (== being liberal in what it accepts).
>>>
>>> ROME will (should) never produce a feed which is invalid (== being strict
>>> in what we send)
>>>
>>>
>>>
>>> That's what we do at the moment - as John M noted, you can parse a RSS
>>> 2.0 feed with a missing channel description. However, you cannot produce the
>>> same thing - you must correct it and make it spec compliant before the feed
>>> will be generated.
>>>
>>>
>>>
>>> Nick
>>>
>>>
>>>
>>>
>>>
>>> From: James Roper [mailto: jroper2@...]
>>> Sent: Friday, 16 January 2009 5:25 PM
>>> To: dev@...
>>> Subject: Re: 2 proposed additions to ROME
>>>
>>>
>>>
>>> In my opinion, the best solution would be for ROME to fix up the feed,
>>> where it can, when parsing it. If it finds that the description element
>>> doesn't have a value, why doesn't the parser just drop it? It does seem
>>> very counter intuitive that the generator can't generate something that the
>>> parser has successfully parsed.
>>>
>>> I don't think being liberal in what something accepts means breaking the
>>> specifications of what its meant to produce. If the feed is invalid, the
>>> parser should make its best attempt to produce something that is valid from
>>> it, or, if it can't produce something valid, fail. There's no half way,
>>> producing something invalid is far worse than just failing outright when the
>>> feed is invalid.
>>>
>>> Cheers,
>>>
>>> James
>>>
>>> On Fri, Jan 16, 2009 at 4:14 PM, Alejandro Abdelnur < tucu00@...>
>>> wrote:
>>>
>>> John,
>>>
>>> A principle behind ROME design was Postel's law: "Be liberal in what you
>>> accept, and conservative in what you send"
>>>
>>> Because of this I would recommend against it.
>>>
>>> Regardless. If you still want to this you can replace the corresponding
>>> Generator with a lenient one.
>>>
>>> A
>>>
>>>
>>>
>>> On Fri, Jan 16, 2009 at 8:37 AM, John M < jmadden73@...> wrote:
>>>
>>> All,
>>> I had an item to bring up as possible extension to ROME.
>>>
>>> It's possible for ROME to successfully parse an invalid feed (for
>>> example in RSS 2.0 the channel description tag is required but ROME can
>>> still parse the feed). However when using ROME to print the feed the
>>> printing will fail with an exception indicating the required tag is missing.
>>>
>>> I'd like to add a feature to allow ROME to still print the feed, even
>>> if the original feed was invalid according to the spec. Think of it as
>>> having 2 print modes: "strict" (the default) and "easy".
>>>
>>> For a concrete example of this see this rss feed:
>>> http://feedproxy.google.com/AbcNews_TopStories?format=xml
>>> It has the channel description tag but no value. It's be nice to be
>>> able to have ROME parse this and then be able to print it.
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> IMPORTANT: This e-mail, including any attachments, may contain private or
>>> confidential information. If you think you may not be the intended
>>> recipient, or if you have received this e-mail in error, please contact the
>>> sender immediately and delete all copies of this e-mail. If you are not the
>>> intended recipient, you must not reproduce any part of this e-mail or
>>> disclose its contents to any other party. This email represents the views of
>>> the individual sender, which do not necessarily reflect those of
>>> Education.au except where the sender expressly states otherwise. It is your
>>> responsibility to scan this email and any files transmitted with it for
>>> viruses or any other defects. education.au limited will not be liable for
>>> any loss, damage or consequence caused directly or indirectly by this email.
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
|
Re: 2 proposed additions to ROME
yes, ROME plugins are not designed to be hot-swappable. in my ROME2 (frozen somewhere in my HD) proto I was doing that. On Tue, Jan 27, 2009 at 3:25 AM, John M <jmadden73@...> wrote:
Okay,
Attached is a proposed 'lenient' generator. However, I was working on writing a test case (to fit into the current Junit testing architecture) and was unable to come up with a good way to test. The only way I could think of would be to have a rome.properties in the same package where my test was -- but won't this potentially impact other tests since the generators get loaded when the WireFeedOutput class gets loaded (and only gets done once)?
It looks like the plugin design was intented to be initialized only once and never modified -- no changes to generators after the code is running.
-John M
On Tue, Jan 20, 2009 at 3:06 PM, John M <jmadden73@...> wrote:
I think the custom generator, with some documentation about how to use it, might be a useful addition. I'll volunteer to write it since I started this thread :-)
I'll get it done soon & submit it as a patch for possible addition to the baseline.
Thanks! This was a very fruitful discussion!
Thanks,
John MOn Tue, Jan 20, 2009 at 12:06 AM, Nick Lothian <nlothian@...> wrote:
I suspect that - from the users point of view - a message like "No description found" is likely to be a bigger problem than ROME erroring.
At least when ROME errors the software developer is likely to see the problem. If ROME inserted default messages like that then the first the developer may know of it is when it is reported by a user.
Fail-fast is a good principle.
I can see the argument for some kind of default generator, but I'd tend towards zero-length strings being the default for string values. I'm not sure what we'd do for dates, though.
I think it's worth pointing out that users can already implement this themselves by creating a custom Generator and changing rome.properties. (They could also send in a patch!)
Nick
-----Original Message-----
From: James Roper [mailto: jroper2@...]
Sent: Tuesday, 20 January 2009 3:26 PM
To: dev@...
Subject: Re: 2 proposed additions to ROME
I think it's a matter of the parser making the right trivial decisions
as it parses. Using the example above, one thing the parser should
do, is when it parses the description tag, if it has no value, insert
a default value, for example "No description found." This makes the
feed internally valid, that is, the SyndFeed object will pass
validation when it gets generated, and it means that applications
using ROME don't need to do their own checks for things that are
supposed to be guaranteed by the RSS spec - this is ROME's job, even
if it is being liberal about what it accepts.
-James
On Tue, Jan 20, 2009 at 3:36 PM, Alejandro Abdelnur < tucu00@...> wrote:
> automatically how? I think this depends on what you are trying to do.
>
> You could have a helper class that traverses the entries of the feed doing
> the check and corrections and after you call this logic you output the feed.
>
> A
>
> On Tue, Jan 20, 2009 at 8:38 AM, John M < jmadden73@...> wrote:
>>
>> Can we have ROME automatically fix the feed? For example, during the feed
>> generation for printing there are a series of checks the ROME generators
>> perform to make sure the generated feed conforms to the spec.
>>
>> How about having the generators "fix' malformed feeds by inserting an
>> empty string, the tag name, etc. in the location where the feed is broken
>> rather than failing with an error. That would be a "lenient" mode ROME
>> could be put into by setting a property in the rome.properties file.
>>
>> This will still make the rule of "liberal with ingest, conservative with
>> output" hold true.
>>
>> Thanks,
>> -John M.
>>
>> On Sun, Jan 18, 2009 at 5:18 PM, Nick Lothian
>> < nlothian@...> wrote:
>>>
>>> I don't quite understand what you are saying here.
>>>
>>>
>>>
>>> There are some cases where ROME can parse a feed which is technically
>>> incorrect (== being liberal in what it accepts).
>>>
>>> ROME will (should) never produce a feed which is invalid (== being strict
>>> in what we send)
>>>
>>>
>>>
>>> That's what we do at the moment - as John M noted, you can parse a RSS
>>> 2.0 feed with a missing channel description. However, you cannot produce the
>>> same thing - you must correct it and make it spec compliant before the feed
>>> will be generated.
>>>
>>>
>>>
>>> Nick
>>>
>>>
>>>
>>>
>>>
>>> From: James Roper [mailto: jroper2@...]
>>> Sent: Friday, 16 January 2009 5:25 PM
>>> To: dev@...
>>> Subject: Re: 2 proposed additions to ROME
>>>
>>>
>>>
>>> In my opinion, the best solution would be for ROME to fix up the feed,
>>> where it can, when parsing it. If it finds that the description element
>>> doesn't have a value, why doesn't the parser just drop it? It does seem
>>> very counter intuitive that the generator can't generate something that the
>>> parser has successfully parsed.
>>>
>>> I don't think being liberal in what something accepts means breaking the
>>> specifications of what its meant to produce. If the feed is invalid, the
>>> parser should make its best attempt to produce something that is valid from
>>> it, or, if it can't produce something valid, fail. There's no half way,
>>> producing something invalid is far worse than just failing outright when the
>>> feed is invalid.
>>>
>>> Cheers,
>>>
>>> James
>>>
>>> On Fri, Jan 16, 2009 at 4:14 PM, Alejandro Abdelnur < tucu00@...>
>>> wrote:
>>>
>>> John,
>>>
>>> A principle behind ROME design was Postel's law: "Be liberal in what you
>>> accept, and conservative in what you send"
>>>
>>> Because of this I would recommend against it.
>>>
>>> Regardless. If you still want to this you can replace the corresponding
>>> Generator with a lenient one.
>>>
>>> A
>>>
>>>
>>>
>>> On Fri, Jan 16, 2009 at 8:37 AM, John M < jmadden73@...> wrote:
>>>
>>> All,
>>> I had an item to bring up as possible extension to ROME.
>>>
>>> It's possible for ROME to successfully parse an invalid feed (for
>>> example in RSS 2.0 the channel description tag is required but ROME can
>>> still parse the feed). However when using ROME to print the feed the
>>> printing will fail with an exception indicating the required tag is missing.
>>>
>>> I'd like to add a feature to allow ROME to still print the feed, even
>>> if the original feed was invalid according to the spec. Think of it as
>>> having 2 print modes: "strict" (the default) and "easy".
>>>
>>> For a concrete example of this see this rss feed:
>>> http://feedproxy.google.com/AbcNews_TopStories?format=xml
>>> It has the channel description tag but no value. It's be nice to be
>>> able to have ROME parse this and then be able to print it.
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> IMPORTANT: This e-mail, including any attachments, may contain private or
>>> confidential information. If you think you may not be the intended
>>> recipient, or if you have received this e-mail in error, please contact the
>>> sender immediately and delete all copies of this e-mail. If you are not the
>>> intended recipient, you must not reproduce any part of this e-mail or
>>> disclose its contents to any other party. This email represents the views of
>>> the individual sender, which do not necessarily reflect those of
>>> Education.au except where the sender expressly states otherwise. It is your
>>> responsibility to scan this email and any files transmitted with it for
>>> viruses or any other defects. education.au limited will not be liable for
>>> any loss, damage or consequence caused directly or indirectly by this email.
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
|
RSS090LenientGenerator.java (6K) 