[feedvalidator] amp;apos; is not HTML

2005-09-19 Thread Anne van Kesteren

Hi,

I could not find the e-mail address from Sam Ruby that fast so I thought I would
e-mail the list.

http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fannevankesteren.nl%2Ffeeds%2Fhref

As Atom 0.3 is deprecated I thought I would update my feeds. As I did not use
anything fancy it was fairly trivial to do only I encountered this bug in the
validator.

I assume it was added to sniff for 'HTML like constructs' only this time the
subject really was apos; and it was not used to double escape for HTML.
Besides that, apos; is not even a valid entity for HTML 4.

Kind regards,

Anne


-- 
Anne van Kesteren
http://annevankesteren.nl/



Re: [feedvalidator] amp;apos; is not HTML

2005-09-19 Thread Graham


On 19 Sep 2005, at 11:20 am, Anne van Kesteren wrote:

I assume it was added to sniff for 'HTML like constructs' only this  
time the
subject really was apos; and it was not used to double escape  
for HTML.

Besides that, apos; is not even a valid entity for HTML 4.


That's why it says Warning instead of Error.
On the other hand, neither of the sentences following it are  
acceptable to me:


This feed is valid, but may cause problems for some users. We  
recommend fixing these problems.


It would be better if the validator admitted it's fallibility and  
said straight up that it doesn't know if these are problems or not.


Graham



Arr! Avast me hearties!

2005-09-19 Thread Eric Scheid

Tis be gettin' t' th' time o' year when pirates be stalking th' deck. Arrr!

(I can't keep that up...)

there's a serious point ... I've just had the dubious pleasure of seeing a
couple of subscriptions have all their entries marked as changed/unread, and
on inspection I see they've flipped the magic switch and all their content
is now appearing in Pirate Speak (via the magic of output filters, and
barrels of rum).

This includes messages posted before official pirate day.

Sometime in the near future I expect they'll sober up, see the day has
passed, and unflip the magic Pirate Speak switch.

And all the subscriptions will again be presented in teh orginal spellig
wonder.

So ... ObAtom ... would recommended practice be to emit the garbled
enunciations inline, with no change to atom:updated, and if there is any
version tracking or modified dates present to also not update those? Make it
look like some blurred illusion, fading from reality like a bad dream the
next day faster than our rum soaked hangovers?

e.



Re: Arr! Avast me hearties!

2005-09-19 Thread A. Pagaltzis

* Eric Scheid [EMAIL PROTECTED] [2005-09-19 19:40]:
 So ... ObAtom ... would recommended practice be to emit the
 garbled enunciations inline, with no change to atom:updated,
 and if there is any version tracking or modified dates present
 to also not update those? Make it look like some blurred
 illusion, fading from reality like a bad dream the next day
 faster than our rum soaked hangovers?

It only has one drawback: if previous entries are presented in
pirate-speak, and then you post new entries meanwhile so that
some of them fall off the bottom of the feed, aggregators which
don’t track versions will keep the pirate-speak version as the
principal one… ugh.

So if you really really really want to deliver all your existing
entries converted to pirate-speak, then make sure that your feed
only grows and does not drop entries, and *keep* it that way for
at least a few days after flipping the switch again.

Considering all this, it would probably be better to restrict
converter pranks to a site’s web browser personality…

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/



Re: Arr! Avast me hearties!

2005-09-19 Thread James Aylett

On Tue, Sep 20, 2005 at 03:31:01AM +1000, Eric Scheid wrote:

 So ... ObAtom ... would recommended practice be to emit the garbled
 enunciations inline, with no change to atom:updated, and if there is
 any version tracking or modified dates present to also not update
 those? Make it look like some blurred illusion, fading from reality
 like a bad dream the next day faster than our rum soaked hangovers?

I think you'd have to just provide an alternative to the entire feed,
labelled in the title somehow. Really it would be nice to do this via
the MIME type, using a language=... parameter to the type, but no such
parameter exists. (And people might laugh at
language=x-piratical-aaargh ... not to mention argue about the number
of 'a's required :-)

James

-- 
/--\
  James Aylett  xapian.org
  [EMAIL PROTECTED]   uncertaintydivision.org



Re: Arr! Avast me hearties!

2005-09-19 Thread James Holderness


My preference would be for a client initiated approach that automatically 
took effect on September the 19th.


A conforming client SHOULD perform an HTTP request for the feed with the 
Accept-Language header set to en-pirate (or whatever the standard RFC 3066 
language tag for the pirate dialect of english). A conforming server SHOULD 
return the pirate version of the feed with the Content-Language header set 
to en-pirate and/or the xml:lang attribute set to en-pirate in the root 
element.


Any feed items that the client had previously received (based on matching 
atom:id and atom:updated elements) MAY be kept as is (i.e. in their original 
source language). However any new messages received would be in the pirate 
dialect.


Future downloads of the feed (after the 19th September) SHOULD return to 
using an Accept-Language header of en-us (or whatever the user's prefered 
language), but any messages that had been received on the 19th MAY remain in 
the client database in the pirate dialect (assuming their atom:id and 
atom:updated elements remain unchanged).


IMHO ;) 



Re: Arr! Avast me hearties!

2005-09-19 Thread Walter Underwood

I think we just got a nomination for an April 1 RFC. Nice job.
More accurate than the x-hacker locale on Google, because that
is really still english, not some other hacker language.
Besides, they didn't make the spell suggest work in l33t.

wunder

--On September 20, 2005 3:09:56 AM +0100 James Holderness [EMAIL PROTECTED] 
wrote:

 A conforming client SHOULD perform an HTTP request for the feed with the 
 Accept-Language header set to en-pirate (or whatever the standard RFC 3066 
 language tag for the pirate dialect of english). A conforming server SHOULD 
 return the pirate version of the feed with the Content-Language header set to 
 en-pirate and/or the xml:lang attribute set to en-pirate in the root 
 element.



--
Walter Underwood
Principal Software Architect, Verity