For yet another reason why aggregators deliver up duplicate entries,
See: http://bobwyman.pubsub.com/main/2005/05/rss_ads_done_th.html
Hopefully, Atom V1.0 will make it easier for us to isolate our users from
the impact of poorly designed advertising programs...
bob wyman
On 2/5/05 10:25 PM, Domel [EMAIL PROTECTED] wrote:
I think that you should add new value to type attribute (3.1.1) - xml
type=xml
This value will allow embed not only text, HTML and XHTML but also
others XML applications like SVG, SMIL etc.
Like in XSLT 2.0 draft in method attribute.
the
Domel wrote:
Many case. Two examples:
1. Selectros in CSS. Now selectors can only be element like * , E, E F,
E F and pseudo-class/pseudo-elements like: E:first-child. But we can't
matche any E element ID. Atom 0.8 support xml:lang so support also
E:lang(c) but there aren't any id attributes
One thought I had to make the TextConstruct and Content more similar
is to have a type attribute in the TextConstruct; however, the
TextConstruct could
be limited to types of text/plain, text/html and text/xhtml. It would
also eliminate the
need for special types of TEXT, HTML and XHTML.
Brett
Example of my type=xml
Support SVG
content type=xml xml:lang=en
text xmlns=http://www.w3.org/2000/svg;
Hello, out there
/text
/content
Dominik Tomaszuk
Anne van Kesteren wrote:
Perhaps I should have been more specific. What is the use case of
styling Atom?
Some people styling feeds. OK, I don't think everybody must styling Atom
but when somebody want why not?
Also, what is the use case for this. What should it actually when
given to a feed
Anne van Kesteren wrote:
What is the use case?
Many case. Two examples:
1. Selectros in CSS. Now selectors can only be element like * , E, E F,
E F and pseudo-class/pseudo-elements like: E:first-child. But we can't
matche any E element ID. Atom 0.8 support xml:lang so support also
E:lang(c) but
Anne van Kesteren wrote:
Yeah why not? That does not have anything to do with Atom mentioning
the xml:id attribute though. Authors can include it themselves if
desired. xml:base and xml:lang solve specific Atom problems, xml:id
doesn't do that. (Atom uses something else to uniquely identify
Brett Lindsley wrote:
text/xhtml
application/xhtml+xml - RFC3236 ;-)
Dominik Tomaszuk
Brett Lindsley wrote:
My thought on this was to treat an embedded XML document as a block
of escaped text and let a processor other than the Atom processor handle
it. Thus, text/plain, text/html and application/xhtml+xml ;-) would all be
processed consistently (as a block of escaped text).
On Mon, May 02, 2005 at 04:42:24PM +0200, Domel wrote:
Example of my type=xml
Support SVG
content type=xml xml:lang=en
text xmlns=http://www.w3.org/2000/svg;
Hello, out there
/text
/content
content type='image/svg+xml' xml:lang='en'
text xmlns=...
Hello, out there
/text
/content
?
--On May 2, 2005 5:32:22 PM +1000 Eric Scheid [EMAIL PROTECTED] wrote:
Counting impressions is essential to their trade, and you'll find that it is
industry standard practice.
Make that was essential, and should be a dying practice. Ads have moved to
results-based billing, paying for
On Monday, May 2, 2005, at 09:48 AM, Walter Underwood wrote:
Counting impressions is essential to their trade, and you'll find
that it is
industry standard practice.
Make that was essential, and should be a dying practice. Ads have
moved to
results-based billing, paying for clickthrough and
James Aylett wrote:
(Assuming text is an acceptable root element for SVG.)
It isn't. application/xml is probably more appropriate.
--
Anne van Kesteren
http://annevankesteren.nl/
On 4/27/05, Bob Wyman [EMAIL PROTECTED] wrote:
Alternatively, if you have a better
method then that proposed by Graham for defending against the attack, please
describe it. Otherwise, Graham's compromise should be accepted and the
specification revised.
Is there a proposal on the table
On May 2, 2005, at 10:30 AM, Robert Sayre wrote:
Alternatively, if you have a better
method then that proposed by Graham for defending against the attack,
please
describe it. Otherwise, Graham's compromise should be accepted and the
specification revised.
Is there a proposal on the table
Domel wrote:
Example of my type=xml
Support SVG
content type=xml xml:lang=en
text xmlns=http://www.w3.org/2000/svg;
Hello, out there
/text
/content
SVG doesn't define embedding in other languages apart from providing a
whole SVG document as defined by the SVG spec, e.g. in an svg element.
http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource
Graham
===
Abstract
Allow multiple version of an entry within a feed where the source id
is different.
Status
Proposed
Rationale
The current spec does not allow multiple versions of the same entry
within a feed. In normal usage,
On Mon, May 02, 2005 at 06:34:44PM +0200, Anne van Kesteren wrote:
James Aylett wrote:
(Assuming text is an acceptable root element for SVG.)
It isn't. application/xml is probably more appropriate.
It would be, if SVG explained how to embed fragments in other XML
dialects. As I understand,
On Mon, May 02, 2005 at 08:48:12AM -0700, Walter Underwood wrote:
Counting impressions is essential to their trade, and you'll find
that it is industry standard practice.
Make that was essential, and should be a dying practice. Ads
have moved to results-based billing, paying for
Not sure if anyone's pointed this out. Section 4.2.9.2 (the rel
Attribute), second paragraph:
The value of rel MUST be string ...
which should probably be ... MUST be a string
James
--
/--\
James Aylett
On Monday, May 2, 2005, at 12:41 PM, Graham wrote:
http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource
Graham
===
Abstract
Allow multiple version of an entry within a feed where the source id
is different.
Status
Proposed
Rationale
The current spec does not allow multiple versions of
4.2.11 The atom:source Element
If an atom:entry is copied from one feed into another feed, then the
source atom:feed's metadata (all child elements of atom:feed other
than the atom:entry elements) MAY be preserved within the copied
entry by adding an atom:source child element, if it
Walter Underwood wrote:
We punted explicit support for ads, so they will continue to show up
in content and cause more work for Bob.
Uhh... It isn't just me. This work needs to be done by just about
anyone who builds an aggregator if they implement duplicate detection based
on analysis
Antone Roundy wrote:
I'd support forbidding any attributes other than (a) namespace
declaration(s) on container elements...in fact, I'm going to add that
to PaceXmlContentWrapper.
Won't that complicate validation a lot?
If the spec is changed to forbid any attribute (other than the XHTML
Antone Roundy wrote:
multiple representations of the same entry resource could appear
in a feed document as long as they were aggregated into the feed
by different routes.
Two rules:
1. You should only write a source element into an entry if it does
not already have one.
2.
On Monday, May 2, 2005, at 03:27 PM, Thomas Broyer wrote:
Antone Roundy wrote:
I'd support forbidding any attributes other than (a) namespace
declaration(s) on container elements...in fact, I'm going to add that
to PaceXmlContentWrapper.
Won't that complicate validation a lot?
Not being a
Graham wrote:
atom:feed elements MUST NOT contain an atom:entry element that has
the same atom:id value as any other atom:entry element, unless both
atom:entry elements each contain an atom:source element, and the two
atom:id values in each atom:source element are different.
-.5
On Monday, May 2, 2005, at 03:37 PM, Bob Wyman wrote:
Antone Roundy wrote:
multiple representations of the same entry resource could appear
in a feed document as long as they were aggregated into the feed
by different routes.
Two rules:
1. You should only write a source element into an entry if
On May 2, 2005, at 2:37 PM, Bob Wyman wrote:
multiple representations of the same entry resource could appear
in a feed document as long as they were aggregated into the feed
by different routes.
Two rules:
Bob, we need spec language. Right now, we have Paces from Graham and
Roundy. Can you
On 2 May 2005, at 10:03 pm, Antone Roundy wrote:
The content of an atom:id element MUST be created in a way that,
as nearly as possible, assures uniqueness. An atom:id value that
has been used with one entry in a particular feed MUST NOT ever be
used with a different entry in the same
These two statements conflict:
It is harder to fake the URI from which a feed is actually read.
as identified in a link element (with rel=self) and the atom:id
of the entry.
rel=self doesn't contain where the feed came from, it contains where
the feed claims it came from, and since it has no
On Monday, May 2, 2005, at 05:23 PM, Graham wrote:
On 2 May 2005, at 10:03 pm, Antone Roundy wrote:
The content of an atom:id element MUST be created in a way that, as
nearly as possible, assures uniqueness. An atom:id value that has
been used with one entry in a particular feed MUST NOT ever
On Monday, May 2, 2005, at 05:33 PM, Graham wrote:
These two statements conflict:
It is harder to fake the URI from which a feed is actually read.
as identified in a link element (with rel=self) and the atom:id of
the entry.
rel=self doesn't contain where the feed came from, it contains where
On 3 May 2005, at 12:49 am, Antone Roundy wrote:
Huh? I thought it contained a URI from which the feed could be
accessed, and that if one were to get the feed from a different
URI, the preferred action would be to fetch it from the self URI
in the future.
No. The spec says simply this:
The
On Monday, May 2, 2005, at 07:22 PM, Bob Wyman wrote:
Antone Roundy asked:
Category feeds: ... Should they, or feeds that combine category
feeds present the entries like aggregated feeds?
Yes, at least normally. An entry should have only one source.
On a site that has a master feed and also
36 matches
Mail list logo
