On Jan 31, 2005, at 03:11, Asbjørn Ulsberg wrote:
On Sun, 30 Jan 2005 22:06:23 +0200, Henri Sivonen [EMAIL PROTECTED]
wrote:
So how many European sites besides the EU have the resources to
provide translations of the *same* content in multiple languages at
the same time?
The company I work in
On Jan 31, 2005, at 03:00, Graham wrote:
Software displaying this text SHOULD remove white-space at the
beginning and end; collapse white-space between words; and disregard
line break, tab and other formatting characters. in 3.1.1 (TEXT).
+1 with the minor nit that lone line breaks should be
On Jan 31, 2005, at 01:32, Sam Ruby wrote:
Julian Reschke wrote:
atomTitle type=XHTML xmlns:xhtml=http://www.w3.org/1999/xhtml;
Less: xhtml:em lt; /xhtml:em
/atomTitle
(hope I got these right).
This is not only right, but also a good example of why many people
would prefer to have another
Robert Sayre wrote:
Agree. -1. Bill needs a private content model. Removing the content
model from Atom will not fix that. I suggest something like
text/bill+xml. Making general-purpose feeds available where one
consumer will only ever use half of the content is bad practice. Use two
Thanks for the feedback, Robert...
Robert Sayre wrote:
- rel attribute is missing
The rel attribute is optional and the relation is considered to be
alternate in that case.
http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute
On 31 Jan 2005, at 4:22 am, Tim Bray wrote:
OFor ongoing, I plan to use the same http: URIs for both the
atom:id and link rel=alternate; I will manage (and have managed)
my URI space so that they will meet the requirements of permanence,
uniqueness, and so on. In this case the atom:id URI will
Sam Ruby wrote:
Julian Reschke wrote:
atomTitle type=XHTML xmlns:xhtml=http://www.w3.org/1999/xhtml;
Less: xhtml:em lt; /xhtml:em
/atomTitle
(hope I got these right).
This is not only right, but also a good example of why many people would
prefer to have another element so that they don't have
Mark Nottingham wrote:
And, if you use XSLT, it's also possible to do it all in-stylesheet,
with or without links.
Safari (and probably other things) don't do XSLT.
Fair enough.
Safari is said to get a (libxml-based) XSLT engine in the next major
upgrade.
Best regards, Julian
--
green/bytes
Henri Sivonen wrote:
On Jan 31, 2005, at 00:53, Robert Sayre wrote:
I think this should come with the following URL:
http://www.oasis-open.org/committees/relax-ng/spec-20011203.html
I don't want to refer to OASIS's URLs.
Why not? Will ISO-Relax NG be available on the Web free of charge? Specs
Julian Reschke wrote:
Thanks for the feedback, Robert...
Robert Sayre wrote:
- rel attribute is missing
The rel attribute is optional and the relation is considered to be
alternate in that case.
http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute
* Robert Sayre wrote:
If I tell NetNewsWire to GET something in the subscribe dialog, my
dispatching instructions are clear. Everything is a feed. Making up
rules for application/xml, text/xml, and application/octet-stream will
require superceding some RFCs that I'd rather not mess with.
What
Robert Sayre wrote:
'atom:head elements MUST contain at least one atom:link element with a
rel attribute value of alternate.'
Point taken. How about 'atom:head elements MUST contain at least one
atom:link element with a relation of alternate.'
Can't we just get rid of the defaulting? That would
Bjoern Hoehrmann wrote:
* Robert Sayre wrote:
If I tell NetNewsWire to GET something in the subscribe dialog, my
dispatching instructions are clear. Everything is a feed. Making up
rules for application/xml, text/xml, and application/octet-stream will
require superceding some RFCs that I'd
Sam Ruby wrote:
Interoperability will be improved if we can nail down what are valid
media types that atom feeds can be served with, and what are invalid
media types that should always be rejected.
We can build voluntary conformance test suites for aggregator
developers to test against.
The
On 31 Jan 2005, at 05:22, Tim Bray wrote:
On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is no requirement for the
content to represent a URI
where a
On Jan 31, 2005, at 4:37 AM, Robert Sayre wrote:
05-C05, 4.15.3 processing model
If the value of type begins with text/ the content of
atom:content MUST NOT contain child elements.
See 4.15.2: so is this a SHOULD or a MUST?
It's a MUST, and not an editorial change.
If it's a MUST then
On Jan 31, 2005, at 5:37 AM, Bjoern Hoehrmann wrote:
* Tim Bray wrote:
Currently, the draft says *nothing* about xml:space (unless I'm
mis-using the search function). If you read the specification for
xml:space (http://www.w3.org/TR/REC-xml/#sec-white-space), all it says
is that this is a
* Henry Story [EMAIL PROTECTED] [2005-01-31 16:25+0100]
On 31 Jan 2005, at 05:22, Tim Bray wrote:
On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is
Tim Bray wrote:
On Jan 31, 2005, at 4:37 AM, Robert Sayre wrote:
05-C05, 4.15.3 processing model
If the value of type begins with text/ the content of
atom:content MUST NOT contain child elements.
See 4.15.2: so is this a SHOULD or a MUST?
It's a MUST, and not an editorial change.
If it's a
On Sun, 30 Jan 2005 19:28:05 -0800, Mark Nottingham [EMAIL PROTECTED] wrote:
How about Dereferencability of Identity Constructs?
That should discourage most everyone from reading that section.
Lance
On 31 Jan 2005, at 3:40 pm, Tim Bray wrote:
Uh, it seems that you're assuming that can be dereferenced is
equivalent to will be unstable. I disagree. -Tim
I agree it's possible for links to be stable. But giving the id a
functional purpose as an address introduces all sorts of reasons to
H. The dead horse comes to life with more beating. At the risk of
causing further consternation and time-wasting...
At 7:28 PM -0800 1/30/05, Mark Nottingham wrote:
How about Dereferencability of Identity Constructs?
Works for me.
At 10:30 PM -0500 1/30/05, Robert Sayre wrote:
Well, it seems
On Jan 31, 2005, at 16:05, Julian Reschke wrote:
Can't we just get rid of the defaulting? That would make the spec
simpler with little additional verbosity in the instance documents.
If there is no default, someone will still omit the attribute and
consumers will try to cope. I think it is
At 11:47 AM -0500 1/31/05, Robert Sayre wrote:
How about this:
[Last sentence of the first paragraph, combined 3.5.1 and 3.5,
altered first paragraph in Comparing]
3.5 Identity Constructs
An Identity construct is an element whose content conveys a
permanent, universally unique identifier
On Sunday, January 30, 2005, at 05:43 PM, Robert Sayre wrote:
How about Make sure your id is unique from a character-by-character
perspective, but also unique in the face of scheme-specific
comparisons. That is, don't lean on scheme-specific comparisons to
match URIs, but they don't have to be
I am not sure this is relevant but all this is supporting IRI?
jfc
At 13:24 31/01/2005, Bjoern Hoehrmann wrote:
* Robert Sayre wrote:
Suppose your user is subscribed to a feed containing 1000 entries. One
day, the host name is no longer capitalized. Are you going to put 1000
new, duplicate
On Jan 31, 2005, at 8:47 AM, Robert Sayre wrote:
Paul Hoffman wrote:
At 10:30 PM -0500 1/30/05, Robert Sayre wrote:
Well, it seems silly to use a dereferencable scheme if you don't
want the URI dereferenced.
I agree, but there was broad WG consensus on this months ago. It is
too late to revisit
On Sunday, January 30, 2005, at 10:25 AM, Tim Bray wrote:
** @type **
The passages in 3.1.1 and 4.15.1 and 4.6.3 around @type are not
consistent.
In 3.1.1 media types are not an option:
[[[
Note that MIME media types [RFC2045] are not acceptable values for
the type attribute.
]]]
in 4.15.1
Bjoern Hoehrmann wrote:
* Robert Sayre wrote:
Suppose your user is subscribed to a feed containing 1000 entries. One
day, the host name is no longer capitalized. Are you going to put 1000
new, duplicate entries in front of the user?
It seems the Working Group is split on the requirements for
On Jan 31, 2005, at 10:31 AM, Antone Roundy wrote:
Another option would be to allow one content with inline content,
and alternative content by reference, eg. (not being careful about
getting language tags correct):
content type=TEXT xml:lang=en_USThis is a pen/content
content type=text/html
Tim Bray wrote:
==
PaceIRI
If no further discussion: It's hard to see how to avoid adopting this
now that IRIs are standards-track RFC.
Pro: 2 Expressed neutral: 1 Contra: 0 Concerns about cost: 3
Conclusion: This is tough.
I thought atom:host was made redundant by the combination of HeadInEntry and
FeedLink...
bob wyman
On Monday, January 31, 2005, at 03:23 PM, Antone Roundy wrote:
1) PaceFeedRecursive enables aggregation by allowing the document
element feed to contain other feeds (but those feeds may not contain
yet other feeds).
Correction: PaceFeedRecursive doesn't contain any language limiting the
depth
On Jan 31, 2005, at 11:45 AM, Tim Bray wrote:
PaceFeedState:
If no further discussion: Like PaceSupersede, this model of publishing
does not (so far) enjoy consensus support.
Partially pro: 2
Contra: 0
Conclusion: Not enough interest. Close it.
If this is the direction we go in on this, that's
At 22:25 31/01/2005, Graham wrote:
I don't know much about IRIs. Is it possible to express them as URIs?
As far as I understand, and this is my problem : I cannot have a formal
response on the following.
- there are various way to support a non ASCII IRI (the majority of the
world needs them -
Both proposals suck equally. HeadInEntry is surprisingly elegant when
you get to thinking about it.
Graham
smime.p7s
Description: S/MIME cryptographic signature
At 08:46 05/02/01, Mark Nottingham wrote:
[[[
x. Managing Feed State
Atom Processors MAY keep state (e.g., metadata in atom:head, entries)
sourced from Atom Feed Documents and combine them with other Atom Feed
Documents, in order to facilitate a contiguous view of the contents of the
feed. The
Graham wrote:
Both proposals suck equally. HeadInEntry is surprisingly elegant when
you get to thinking about it.
My preferences are as follows:
1.) PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and
atom:content
2.) RDF (instead of the fake RDF in #4)
3.) add an attribute to
I have just looked at the text in question in -05.txt,
and read through the discussion. I'll give my comments
here, but they are not specifically on this mail.
First, for me, the goal of having reproducible id comparison
is most important; this is the basic requirement.
Second, given that there
On Monday, January 31, 2005, at 08:51 PM, Robert Sayre wrote:
Graham wrote:
Both proposals suck equally. HeadInEntry is surprisingly elegant when
you get to thinking about it.
My preferences are as follows:
1.) PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and
atom:content
2.) RDF
Antone Roundy wrote:
My preferences:
+1: Current draft or PaceAggregationDocument (with or without
atom:feed/atom:head and with or without metadata for atom:aggregation
(atom:aggregation/atom:head?))
+0.5: PaceFeedRecursive without any more indirection than we already
have, and only one level
On Jan 31, 2005, at 8:20 PM, Graham wrote:
This makes it clear that we are talking about here is how
you do it, rather than here's one way to do it.
We might be treading on toes making that assertion.
Yes, but it's not only correct, it's good advice, so we should put it
in.
4) Add a
Robert Sayre wrote:
4) Add a sentence saying something like Feeds or Entries
are identical if their IDs compare identical..
Seems obvious, but isn't stated anywhere.
No. Feeds/entries with the same id are different versions or
instances of a common ancestor. They are not the same.
Martin
On Jan 31, 2005, at 7:10 PM, Martin Duerst wrote:
5) Add a note saying something like Comparison functions
provided by many URI classes/implementations make additional
assumptions about equality that are not true for Identity
Constructs. Atom processors therefore should use simple
There is no reason to require any particular comparison algorithm.
One application is going to compare them the same way every time.
Two different applications may reach different conclusions about
two equivalent identifiers, but nobody cares because AT WORST the
result is a bit of inefficient use
On Jan 31, 2005, at 8:40 PM, Tim Bray wrote:
Graham's right, the word identical is wrong, because in fact you
will commonly encounter two instances of the same entry which aren't
identical (e.g. the one in your cache and the one you just fetched).
I suggest Software MUST treat any two entries
I have just submitted an update to the Atom Notification Protocol
draft that will hopefully be published in a day or so. I have
attached the draft for review.
Summary of changes:
* Rather than POSTing atom:feed elements to indicate an updated
feed, atom:head elements are POSTed.
* Eliminated
47 matches
Mail list logo
