ill tell them that IRI. For
entry-level such links, I would expect the same: where could I
download this "file" when nobody gave me its IRI?
--
Thomas Broyer
in)?
Yes, you could, in the sense that the Atom document wouldn't be
"invalid", but you shouldn't expect it to be processed as a "full HTML
document".
The "SHOULD" implies that Atom processors are OK if they process HTML
"content" as "innerHTML" on a element.
--
Thomas Broyer
d the media-type-parameter option.
If a few people were to put up their hands and say "yeah what Bob said"
your co-chairs would probably do a hasty consensus grab.
Just in case: "yeah what Bob said" ;-)
--
Thomas Broyer
2006/12/14, Bob Wyman:
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
It was exactly the point behind my proposal for this 'type' parameter.
--
Thomas Broyer
;;
type="application/atom+xml" title="Mozillazine News">
My last point: if the rel="feed" as described above seems useless,
then I'm not opposed to having a rel="feed" "marker" as defined in the
current HTML5 draft, with an addition: that this "feed" marker be
"combinable" with any link rel: rel="feed alternate", rel="feed up",
rel="feed index", etc. (and at the condition that it is explicitely
defined as a "marker" and not as a relationship; rel="prefetch" and
rel="nofollow" would also need this distinction).
--
Thomas Broyer
t; would be much more explicit.
Why should it be automated?
When you go read a web site every morning because you know it's
"live", it's not automated. What you could automate is how to go read
that site (e.g. use it as your browser's "start page", or include it
in a bunch of bookmarks you "open in tabs" every morning).
There's not always a need to automate everything. Things like "whether
it'd be interesting to subscribe to something" are better handled by
humans than computers.
--
Thomas Broyer
ementations.
I'd prefer basing autodiscovery on the media types and not at all on
the relationships. A "feed" relationship would only help finding the
"living resource" (similar to rel="current" in the Atom Relationship
Registry) if you're not already "on" it (in which case,
rel="alternate" would be used).
UAs would then obviously continue to support autodiscovery using
"alternate" all-over-the-place, this would just be a lucky
side-effect; and everyone would be happy.
--
Thomas Broyer
r Tim's concerns, I'd also prefer having it done outside the APP.
Also, the APP draft would need to be updated to remove the "entry"
special value for app:accept, as it would be equivalent to the new or
revised media type (app:accept=application/atom+xml;type=entry or
app:accept=applicationAtom.entry+xml)
--
Thomas Broyer
fully
backwards compatible with the current one (which shipped a year ago).
3. We define a new media type for Atom Entry Documents,
e.g. application/atomentry+xml
-1
--
Thomas Broyer
ady done, be sure I'll try to "kiil it before it's done".
--
Thomas Broyer
2006/11/28, Robert Sayre:
The WHAT-WG text is fine.
-1
For various reasons, including:
http://www.imc.org/atom-syntax/mail-archive/msg19100.html
http://www.imc.org/atom-syntax/mail-archive/msg19107.html
--
Thomas Broyer
2006/11/24, Henri Sivonen:
On Nov 24, 2006, at 10:28, Thomas Broyer wrote:
> My main problem with autodiscovery is this use case: the following
> links on an "entry page" in a blog-like scenario, where comments on
> the entry are shown at the bottom of the page:
> ti
2006/11/23, Henry Story:
On 23 Nov 2006, at 14:28, Thomas Broyer wrote:
>
>> "The feed keyword indicates that the referenced document is a
>> syndication feed.
>
> "Being a syndication feed" is expressed by the media type, there's no
> need for a
e "contents" value in
the example above:
in "blog-like" use-cases where an HTML page serves the same purpose as
a syndication feed, just in an 'alternate' format.
--
Thomas Broyer
content.
Right, but I hope and expect those aggregators to either be updated or
tend to disappear (because people will switch to "better"
aggregators).
--
Thomas Broyer
2006/11/2, Henry Story:
On 2 Nov 2006, at 12:19, Thomas Broyer wrote:
>
>> [[
>> The "term" attribute is a string that identifies the category to
>> which the entry or feed belongs. Category elements MUST have a "term"
>> attribute.
>> ]]
&
2006/11/2, Henry Story:
On 2 Nov 2006, at 08:59, Thomas Broyer wrote:
> [redirecting to atom-syntax]
This is also a protocol issue, because we are asking what to do with
the information in the atom feed. [1]
Not sure how atom-protocol is concerned but let's keep it in
atom-prot
;
label="cats"
/>
--
Thomas Broyer
ot;inactivity". That's pretty easy in ASP.NET
developments as the Cache object is provided out-of-the-box; there
should be equivalents in the Java world too.
--
Thomas Broyer
2006/10/26, Gopalan Sri:
http://example.com/"; type="application/atom+xml"
action="POST">
I hope such a thing won't ever exist !!!
--
Thomas Broyer
atom:* element, and child elements and text inside
other elements (atom:category, atom:link, etc.)
Whether the application knows what to do with markup, it's still
extension markup (e.g. thr:in-reply-to) or undefined markup (e.g.
thr:replies-count).
--
Thomas Broyer
m within 2 Feed
Documents form a "stable subset".
If every Feed Document is "stable", then you have an Archived Feed an
dyou can link Feed Documents to each others using next-archive and
prev-archive.
--
Thomas Broyer
'enterprisey' use cases :-)
Have you looked at this?
http://tools.ietf.org/wg/atompub/draft-snell-atompub-revision-00.txt
--
Thomas Broyer
ot match the
> "accepted languages".
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7
so, do not return the requested language alternate?
Hmm, sorry, I think I didn't correctly understood you first question...
...at least I don't understand the second...
--
Thomas Broyer
happen if you used conneg on the @rel='self' link (to the
document), asking for a different language?
You mean, sending an Accept-Language request-header?
406 Not Acceptable or return the entry even if it does not match the
"accepted languages".
http://www.w3.org/Protocol
a book in English and then the translation of that book
in a different language you will end up with two books having each their
own ISBN.
Well, actually, once a book is published, if you later update it,
you'll have to use a new ISBN, so that's probably not a good analogy…
--
Thomas Broyer
ot;if an
aggregator is given a copy of a feed without information about its
original IRI, how can it find which URI to subscribe to?"…
--
Thomas Broyer
ame scheme and term, aggregators (or other Atom processors)
are very likely to consider them the exact same category.
I think the producer of such a feed would be wrong using the same
scheme and term for (conceptually) different categories...
--
Thomas Broyer
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.13.6>).
But using A-IM, you'll have Cache-Control and Vary headers in
responses, which should take care of that, no?
(I'm at work have no time to read the pointed section carefully, so
please forgive me if I'm wrong)
--
Thomas Broyer
2006/6/8, Mark Nottingham <[EMAIL PROTECTED]>:
On 2006/06/07, at 11:40 PM, Thomas Broyer wrote:
>
> My main concern is that RFC3229 w/ feeds is being deployed more and
> more widely and is still not even an I-D (or I missed something).
I have that concern as well.
I am also
2006/6/8, James Holderness <[EMAIL PROTECTED]>:
Thomas Broyer wrote:
> That means you need to keep entry revisions as well, so that if an
> entry is updated while a client is navigating the paged result set, it
> is sent the "old" revision (corresponding to the "
t even an I-D (or I missed something).
Maybe FH could be the place to spec it, as another optimization
algorithm…
[1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html
--
Thomas Broyer
2006/6/7, Robert Yates <[EMAIL PROTECTED]>:
Thomas Broyer wrote:
> and that this is needed because entries
> might not always be atomically retrieved (otherwise, "permaLinks"
> would been enough).
I don't understand what you mean "atomically retrieved"
left undefined in the spec, and I
personnaly have no opinion at all (as I have been given such feeds,
and a) I'm not subscribed to any aggregate feed and b) I don't
aggregate feeds I'm subscribed to, each one lives in its own "folder"
in Thunderbird)…
--
Thomas Broyer
it
would retrieve the feed twice (at least), using If-Modified-Since
and/or If-Not-Match for the second request, and showing a warning if
the feed hasn't changed and the second GET didn't result in a 304 (Not
Modified).
Please note that I haven't went back read the FH draft since weeks, so
some of my comments might not be accurate (I've a pretty good memory
but data-losses might still happen ;-) )
--
Thomas Broyer
y around [1], but for
different reasons. If it's clear that previous/next deals with "pages"
or "chunks" of the same feed, then I'm OK with them, and other use
cases will need new rel values.
[1] http://www.imc.org/atom-syntax/mail-archive/msg17372.html
Given the above, I'd like to see if anyone would still object to
having separate relation sets for incremental feeds ("prev-archive"
and friends) and paging feeds ("previous", "next" and friends).
Given the above, yes. Consider it a "-0" though, not a "-1", as I
might need some more thinking (or people trying to convince me).
--
Thomas Broyer
d like XML.com to provide an "articles only" feed
instead of their "articles and blogs" feed, but that's not a matter of
categories –"columns" are a category for articles, and blog posts have
their own categories–).
In conclusion: YAGNI.
[1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt
--
Thomas Broyer
ttribute telling which encoding
has been used, which would lead to complains that this attribute's
value set isn't extensible…
So no, Atom shouldn't have to support other baseNN encodings than
base64, and doing so wouldn't prove good for interop, so this revised
RFC doesn't break Atom.
--
Thomas Broyer
if "steps" is negative and "minimum" is not "unbounded", replace
"minimum" with the smallest allowable value and use a positive "steps"
value
- if "steps" is negative and "minimum" is "unbounded", replace
"maximum" with the value of "origin" and use a positive "steps" value
(which will count downwards to negative infinity)
- if "steps" is positive, replace "minimum" with the value of "origin"
The following examples illustrate how different sets of rank values can
be defined by means of a single r:value element:
Could be expressed as:
or
or with the following r:values:
--
Thomas Broyer
, I think using attributes directly on atom:link is the
thing to do, waiting for an amendment to RFC4287 to invite
processors/parsers not to discard that extra metadata. The other
choice is to totally remove those attributes, which is what you
finally chose, I can't blame you.
--
Thomas Broyer
tiple "replies" link
is, e.g., having a "comments" and a "trackbacks/pingbacks" feeds
(could be distinguished by [EMAIL PROTECTED]). In this case, having a
@count per link is IMO somewhat important. So -1.
--
Thomas Broyer
nt.fm/blog/archives/000721.html]
I know what your answer is [http://www.snellspace.com/wp/?p=297] but I
also think that these are entry properties, not really link properties
(so I disagree with you on "First, The thr:count and thr:when
properties are specific to the replies link upon which they appear."
[http://www.snellspace.com/wp/?p=296]).
--
Thomas Broyer
ention in my opinion. When reading an XML
> document I don't want to be obliged to think about the actual meaning of
> an id attribute. You are indeed right (and thank you for explaining it
> to me) in terms of specification but conventions are often as important.
> Specially for people like me who are not XML guru.
Well, I wouldn't describe myself as an XML guru either ;-)
--
Thomas Broyer
rent from "id"
- there wouldn't have been a need for xml:id [http://www.w3.org/TR/xml-id/]
> I would rather move the content of that attribute as a text element of the
> 'in-reply-to' element (as does the atom:id element).
Eventually, I'd rather rename it to resource-id…
--
Thomas Broyer
explicit type
"anyURI" that includes IRIs and IRI references. Therefore, IRIs
and IRI references can be in attributes and elements of type
"anyURI".
So, actually, it seems that the Atom RNC could say "atomUri = xs:anyURI".
...or RFC 3987 is wrong... (I didn't check XMLSchema to try to figure
it out myself)
--
Thomas Broyer
[on atom-syntax only, no need to CC atom-protocol]
2006/2/1, David Powell <[EMAIL PROTECTED]>:
>
> Wednesday, February 1, 2006, 3:20:23 PM, Thomas Broyer wrote:
> >
> > IIRC, it was to allow a feed listing "revisions" of the same entry:
> > same id, differ
recise, it is "Entries in an Atom Feed Document" not "Entries
> in an Atom feed".
>
> I really really dislike that rule, and don't understand how it was
> ever accepted, and personally I would be tempted to ignore it.
IIRC, it was to allow a feed listing "revisions" of the same entry:
same id, different "updated" values.
--
Thomas Broyer
#x27;t think that means what you think it means". At least, if you
> mean for search engines not to follow the link. If you just want the
> PageRank of the destination feed (?) to be unaffected by the PageRank of
> the source URL, then yeah, I guess...
Right!
How about robots.txt?
http://www.robotstxt.org/wc/exclusion.html#robotstxt
--
Thomas Broyer
py link address"/paste)
And, follow those guidelines:
http://www.scottfrancis.com/blog/2006/01/21/ui-updates/
* oops, sorry, there's no "type" parameter to the application/atom+xml
type… so let's say
--
Thomas Broyer
7;t it? (however,
it's arguable: should a deletion be silent? how about adding a
del:when in the del:deleted? the atom:updated would then continue to
serve its role: whether to bring the entry to the user's attention)
Just thinking out loud…
--
Thomas Broyer
ves.
[…]
> Anyway, that's my preference. Not necessarily a SHOULD recommendation - just
> my personal opinion.
+1
Maybe at:by and at:comment could be used in pub:control in the APP as well
--
Thomas Broyer
2006/1/21, Anne van Kesteren <[EMAIL PROTECTED]>:
> Quoting Thomas Broyer <[EMAIL PROTECTED]>:
> > Why not use the "media" attribute?
>
> Because that would be "tag abuse".
No more than using the @rel value (is a feed an alternate for a
single-entr
rameterized"
value (e.g. "subscribe audio", "subscribe video", "subscribe text",
"subscribe audio video", etc.)
--
Thomas Broyer
gory | ...) {
text
}
...
> So if my reading is correct, the (normative) spec disagrees with
> the (informal) schema. I'd say that is what's confusing.
Your reading was incorrect (w.r.t. my reading ;-) ) but the
(normative) spec effectively disagrees with the (informal) schema.
--
Thomas Broyer
ake all three.
How about:
Not really equivalent to [EMAIL PROTECTED]"enclosure"] though
--
Thomas Broyer
James Holderness wrote:
>
> Thomas Broyer wrote:
>> As I already explained, paging is orthogonal to the incremental nature
>> of a feed. An incremental feed will be chunked as explained in Mark's
>> current Feed History draft (just use an atom:[EMAIL PROTECTED]
50 web site I
saw didn't provide archives of previous rankings).
When there'll be such a need, then we'll define a new link relation (I
already proposed "archives"/"history" to link to a "table of contents"
feed allowing navigation to e.g. snapshots of non-i
Thomas Broyer wrote:
However, an incremental feed could take advantage of differentiating
between paging and "archive linking": if linking to archives uses an
atom:[EMAIL PROTECTED]"archives"] (or call it "history" if you prefer) to
point at an incremental feed
James Holderness wrote:
Thomas Broyer wrote:
You didn't answer my last question:
How do you expect a newsreader to *automatically* download this
week's 50 entries without downloading last week's entries instead?
(and show you links/buttons for you to ask download and displ
James M Snell wrote:
Thomas Broyer wrote:
You didn't answer my last question:
How do you expect a newsreader to *automatically* download this
week's 50 entries without downloading last week's entries instead?
(and show you links/buttons for you to ask download and display of
James M Snell wrote :
Thomas Broyer wrote:
So you are OK with these feeds:
Yes, they all look good to me.
You didn't answer my last question:
How do you expect a newsreader to *automatically* download this
week's 50 entries without downloading last week's entries instead
James M Snell wrote :
Thomas Broyer wrote:
How would you use these link relations for feed state reconstruction
(that is, automatic handling by the Atom processor, without user
action –except probably the "please reconstruct this feed's state"
action) if you can't kn
James M Snell a écrit :
Thomas Broyer wrote:
Mark Nottingham wrote:
- Attribute Value: previous
- Description: A URI that refers to the immediately preceding
document in a series of documents.
This definition doesn't prevent someone from using this link relation
for
linking wit
senting, say a "webring", where
"previous" and "next" will be other sites' feeds.
I really think we should make it clear that first/previous/next/last are
meant for "paging" of a single feed only.
I'll try to propose a replacement text.
> - Attribute Value: subscribe
+1
--
Thomas Broyer
Thomas Broyer wrote:
Mark Nottingham wrote:
Perhaps people could +1/-1 the following options:
* Reconstructing a feed should use:
a) a specific relation, e.g., "prev-archive"
-1, (see James' comments)
b) a generic relation, e.g., "previous"
+1
Hmm, I migh
Mark Nottingham wrote:
Perhaps people could +1/-1 the following options:
* Reconstructing a feed should use:
a) a specific relation, e.g., "prev-archive"
-1, (see James' comments)
b) a generic relation, e.g., "previous"
+1
--
Thomas Broyer
ugust, etc), then use something like @rel="archives"
or @rel="history", or define a @rel="previous-archive" if you really want
to navigate directly to the other feed without having to go through a
"table of contents" feed.
If some people here prefers "next-chunk" or "next-page" to just "next",
why not, my mind is open
--
Thomas Broyer
Eric Scheid wrote:
On 18/10/05 6:14 PM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
Yes, and navigating through the historical states of the feed resource is
not paging, it's more like having access to archives.
I was thinking about proposing yet another link relati
ev/end link relations
(hasn't James already asked them?) and if they haven't, then we (the WG)
should first agree on the terms to be used (start/end vs. first/last),
request registration and tell the OpenSearch people that these relations
are pending registration.
Any thoughts?
--
Thomas Broyer
no
...
Archive feed:
yes
...
September 2005 Top 100
...
August 2005 Top 100
...
...
September 2005 Top 100 feed:
September 2005 Top 100
no
...
--
Thomas Broyer
James M Snell wrote:
>
> Thomas Broyer wrote:
>> Depends whether @rel="self" was really meant for subscribing and the
>> spec wording is not precise enough about it; this could then be fixed
>> with an errata rather than create a new link relation
>&
sorted (thus paged)
differently, then that's another feed.
--
Thomas Broyer
registration, I don't really matter), and
orthogonally define an fh:incremental extension (fh:incremental will
just change newsreaders behavior, not the paging concept).
It seems James is having the same feeling…
--
Thomas Broyer
equested.
Depends whether @rel="self" was really meant for subscribing and the
spec wording is not precise enough about it; this could then be fixed
with an errata rather than create a new link relation…
Otherwise, +0.5, because it seems to overlap @rel="first" (or "last"?) –
or I missed something…
--
Thomas Broyer
ents themselves) have to be in a specific order in order
to reconstruct the history.
It should (not SHOULD!) however be based on atom:updated or something
similar (e.g. my-ext:last-modified)
--
Thomas Broyer
g (can a
non-incremental feed be paged? does it mean something different than
paging of an incremental feed?)
- eventually a spec defining links to archives (which in turn may use
paging: think about archives of search results, what did the same query
return yesterday, last week, last month, etc.)
--
Thomas Broyer
cerns were that readers/aggregators generally
keep a local history of the feeds they're subscribed to.
fh:incremental=no would explicitly tell them not to do so.
--
Thomas Broyer
ontaining element" the same as
"an alternate version of the resource described by the containing element"?
2. Is the answer to 1. is no then what does "a resource equivalent …"
mean? Is it really different than "the URI you should subscribe to" (at
least if @type="application/atom+xml")?
--
Thomas Broyer
eeds
sorted by date/time or some other "priority" (e.g. OpenSearch results)?
--
Thomas Broyer
quot; (comment added on an entry,
similar to "comment submission HTML forms"). Local comments must use
atom:content and shouldn't use atom:summary. »
(see http://www.imc.org/atom-protocol/mail-archive/msg01384.html for the
complete discussion)
--
Thomas Broyer
James Holderness wrote:
> Thomas Broyer wrote:
>> Compare their atom:[EMAIL PROTECTED]"self" and
>> @type="application/atom+xml"]/@href, they'll point you to the "start" of
>> the "list", the one whose author and copyright appl
CTED]"self"]/@href as the one
found in history documents, aggregators should subscribe to that URI and
not the "borrower"'s one, so the "borrower" can't claim anything.
I think atom:[EMAIL PROTECTED]"self"] is sufficient, there's no need for a
"next".
--
Thomas Broyer
local name to effect versioning -- will be
lost, all for the sake of saving a few characters. Not worth it, IMO.
-1 to ACE, for the very same reasons.
--
Thomas Broyer
ot;last version" links to CSS2 and DOM Level 2 recommendations:
http://www.w3.org/TR/REC-CSS2
http://www.w3.org/TR/DOM-Level-2-Core
http://www.w3.org/TR/DOM-Level-2-HTML
http://www.w3.org/TR/DOM-Level-2-Style
http://www.w3.org/TR/DOM-Level-2-Views
…
I really don't understand why you're disc
lns() XPointer scheme). That way, you could use any
element/subelement and/or attribute as the value holder for the sort.
This would require however an XPath/XPointer engine, as well as storing
the XML DOM, or mapping XPath/XPointer to your internal feed
representation; this is not feasible.
[1]
http://msdn.microsoft.com/windowsvista/building/rss/simplefeedextensions/
--
Thomas Broyer
w.w3.org/2005/Atom";>
...
tag:first-in-list
Another entry
...
tag:second-in-list
Yet another entry
...
Note how tag:first-in-list entry now represents "Another entry" while it
were previously "Some entry", and tag:second-in-list now is "Yet another
entry" while it were "Another entry".
--
Thomas Broyer
ready rose this up in late May [1]. That was before format-09...
[1] http://www.imc.org/atom-syntax/mail-archive/msg15863.html
--
Thomas Broyer
source, create a new link/@rel
value or use a [EMAIL PROTECTED]"related"] or [EMAIL PROTECTED]"via"] or something
like that.
So a strong +1 to making the id REQUIRED.
--
Thomas Broyer
one category per entry; or
using an extension "control information" not supported by the
server: it should be able to tell the client which one has been
refused; etc.)
--
Thomas Broyer
s overrides the set of feed level links.
If I understand correctly, ".../root" tells you where to find the entry
identified with ".../in-reply-to". How are you dealing with multiple
in-reply-to?
If I misunderstood, what is ".../root" for?
--
Thomas Broyer
Antone Roundy wrote:
>
> On Wednesday, July 20, 2005, at 11:44 AM, Thomas Broyer wrote:
>> I was actually wondering why non-stateful feeds couldn't have
>> archives: in the "This month's Top 10 records" feed, why couldn't I
>> link to "Last
This mail has been around in my drafts folder for about 10 days, but
here it is...
I'm not sure what my position is wrt what I wrote below...
Mark Nottingham wrote:
On 04/07/2005, at 6:18 PM, Thomas Broyer wrote:
With the -01 draft (it might have been the same within the -00 one
isting @rel="related"? The question hinges on whether or
not it is semantically important to distinguish "comments" from other
types of related entities. I'm not convinced it is. If a
@link="related" points to an Atom feed, who cares what that feed
contains, the user agent can make the feed available for the user to
subscribe to pulling in the relevant entries.
I don't know yet...
--
Thomas Broyer
qual to
http://example.org/2003/10/index.atom (october, not november). However,
I didn't miss any entry.
Using the fh:[EMAIL PROTECTED] value, I can know that I didn't miss any entry
and that I then don't need to dereference
http://example.org/2003/11/index.atom (november, the "new" fh:prev URI)
--
Thomas Broyer
://example.com/2005/05/"; />
http://example.com/2005/06/
...
or
http://example.com/2005/05/";
fs:updated="2005-05-31T23:59:59" />
...
One advantage of the latter is that you don't rely on URIs as identifiers
for the feed archive documents and they can be moved/split/merged without
readers and aggregators being then implicitly told to retrieve back the
whole archives (if you change URIs, they'll think they missed entries...).
--
Thomas Broyer
s last monday and not at all on sunday) ?
If I can just link to the "latest archive feed document", shouldn't we
then just have an "archive" [EMAIL PROTECTED] in the "live feeds" (similar to
the
"List-Archive" header in mail messages) and use "prev" only between
"archive feed documents" (similar to the "Next Page" link in the HTML list
archive).
--
Thomas Broyer
e would "default" to "text", but "text" is forbidden
if "src" is provided...
I suggest that if src is provided but not type, there is no "type
value", as this value is just advisory and not authoritative. However,
if src is not provided (the content is local), processors must "behave
as though it were present with a value of text".
--
Thomas Broyer
RSS".
The Atom result document could also link to the next and previous
"pages" with additional atom:link elements in the atom:feed, with
"extended" @rel values.
[1] http://opensearch.a9.com/spec/opensearchrss/1.0/
[2] http://www.ltgt.net/atom/opensearch.atom
[3] http://opensearch.a9.com/spec/opensearchdescription/1.0/
--
Thomas Broyer
David Powell wrote:
>
> Quoting Thomas Broyer:
>
>> The problem come when I use a "plain flowed text" and can then omit
>> the "type" attribute:
>> By Thomas Broyer and al.
>> My extension becomes a Simple Extension Element when processed
uctured Extension Element (as it comes in atom:feed, atom:entry or
atom:source):
By Thomas Broyer and al.
By <a href="http://www.ltgt.net/";>Thomas
Broyer</a> and al.
By http://www.ltgt.net/";>Thomas Broyer and al.
The problem come when I use a "plain flowe
1 - 100 of 202 matches
Mail list logo
