Martin Duerst wrote:
...
Bjoern was making a vaild, but fine, point: Because we decided to
refer to RFC2396bis, rather than to RFC2396, we already have bought
into the fact that RFC2396bis allows percent-encoded domain names,
and thus essentially requires IDN support. (apart from the basic
fact
* Ray Slakinski [EMAIL PROTECTED] [2005-01-25 10:40-0500]
+1 from me, I'm happy to see this added!
+1 likewise to http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix
Dan
On 24-Jan-05, at 7:18 PM, Tim Bray wrote:
If there were no further discussion: Got no -1's, seems useful, needed
On Wed, 26 Jan 2005 01:20:58 +, David Powell [EMAIL PROTECTED] wrote:
PaceAttributesNamespace
I'm -1 on this. It seems to be authorising a RDF users to do a
transform on Atom Syntax in order to make it more RDF/XML-like.
That's really orthogonal from the intention.
If RDF users
I've added the following note to the Pace:
A lot of the critical response to this Pace has been based on the
assumption that it is about changes to the Atom syntax. Nothing could
be farther from the truth. Within Atom format it will remain mandatory
that documents are produced with no-namespace
At 13:01 05/01/26, Eric Scheid wrote:
It's only clear what's going on when the reader juxtaposes the two sections,
and realises that the concept named 'type' in section [3.1.1] is not the
same concept named 'type' in section [3.5.2]. Without that juxtaposition,
the reader might well never realise
Danny Ayers wrote:
I've added the following note to the Pace:
A lot of the critical response to this Pace has been based on the
assumption that it is about changes to the Atom syntax. Nothing could
be farther from the truth. Within Atom format it will remain mandatory
that documents are produced
On Wednesday, January 26, 2005, at 07:03 AM, Sam Ruby wrote:
Let's assume that there will be a non-normative appendix which
describes the mapping of the Atom/XML syntax to RDF triples (possibly
via a mapping to RDF/XML or possibly directly). Clearly, such an
appendix would need to define a
On 26 Jan 2005, at 2:37 am, Eric Scheid wrote:
I also concur. An aggregator is free to do so, but I don't think it
should
be a requirement. We already have a mechanism for the publisher to
redirect
requests to a new location (HTTP 304, 301).
An aggregator might also only do so in extremis - if
On Jan 26, 2005, at 7:27 AM, Graham wrote:
Very, very good point. The text needs something along the lines of
Atom producers MUST NOT expect consumers which found the document at
a different URI to switch to requesting it from the URI specified.,
or something less clunky. Otherwise it's going
On 26 Jan 2005, at 15:03, Sam Ruby wrote:
[...]
But, now lets examine the statement proposed in
PaceAttributeNamespace. It essentially alerts producers of something
that that they need to be aware of. Now a quesion: what do they need
do different with the knowledge that the RDF mapping does
Graham the Robot [1], when real people come and ask me something I'll
talk to them.
Henry
On 26 Jan 2005, at 18:01, Graham wrote:
On 26 Jan 2005, at 4:37 pm, Henry Story wrote:
I think your assertion is wrong. If they are consuming or producing
extended Atom [1]
they will know exactly what
+1 on PaceIRI
I'm a little hesitant on this because I'm not familiar with the
issues, but it's something we'll probably all have to broach sometime
soon. Martin seems to know what he's talking about ;-)
On Wed, 26 Jan 2005 08:54:51 +0100, Julian Reschke
[EMAIL PROTECTED] wrote:
Martin Duerst
On Tue, 25 Jan 2005 02:10:28 +, David Powell [EMAIL PROTECTED] wrote:
+1
(allowing room for tweaks)
I'll try to post my suggested RDF road-map tomorrow - basically, I'd
like to see:
* an Atom syntax - RDF mapping defined in a separate I-D.
* no changes to the Atom syntax for the
Quoting from draft-ietf-atompub-format-04:
3.1.1 type Attribute
...
If the value is TEXT, the content of the Text construct MUST NOT
contain child elements. Such text is intended to be presented to
humans in a readable fashion. Thus, software MAY display it using
normal text
On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote:
What's the difference between:
atom:title type='TEXT'I do not like
![CDATA[]]marqueegt;/atom:title
and
atom:title type='XHTML'I do not like
![CDATA[]]marqueegt;/atom:title
?
Shouldn't both render as I do not like marquee?
Yeah, but if you
On Jan 26, 2005, at 23:18, Tim Bray wrote:
On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote:
What's the difference between:
atom:title type='TEXT'I do not like
![CDATA[]]marqueegt;/atom:title
and
atom:title type='XHTML'I do not like
![CDATA[]]marqueegt;/atom:title
?
Shouldn't both render
On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote:
FWIW, with the exception of content, I think allowing only %inline XHTML
elements would make more sense than allowing %flow.
On Wed, 26 Jan 2005, Tim Bray wrote:
Anyone else pro or con on this one? -Tim
This has elegance and is intuitively
On Jan 26, 2005, at 1:31 PM, Henri Sivonen wrote:
But if you can always substitute type='TEXT' with type='XHTML' but not
the other way round, what's the point of having type='TEXT' in the
spec?
With type='TEXT' you know it's not going to contain any (X)HTML
formatting, so you don't have to
On Jan 27, 2005, at 00:45, Robert Sayre wrote:
But guess what, TEXT is *never* coming out of the spec, because it
will eventually become impossible to write something that looks like
markup if we don't have it.
How so? What does type='TEXT' make possible to write that type='XHTML'
with a single
On 27/1/05 7:47 AM, Sjoerd Visscher [EMAIL PROTECTED] wrote:
The whole point of xml:base is that an application that stores a page
outside of its original context can add an xml:base to prevent losing
the original location context.
browsers don't.
all they know is here is a URL to a
On 27/1/05 9:24 AM, Henri Sivonen [EMAIL PROTECTED] wrote:
Sorry, I don't understand what your example is demonstrating.
How would the above be different from:
title
type='XHTML'Iamp;nbsp;doamp;nbsp;notamp;nbsp;likeamp;nbsp;lt;
marquee/title
title type='XHTML'Ido not like
On Jan 26, 2005, at 5:03 PM, Graham wrote:
On 26 Jan 2005, at 8:00 pm, Tim Bray wrote:
Hearing no objections, I modified the Pace to say the image SHOULD
have an aspect ratio of 2 (horizontal) to 1 (vertical). -Tim
What's our story on favicons? Quite a few programs support them and
most
On Jan 26, 2005, at 5:54 PM, Brent Simmons wrote:
I agree with that. It's something many feed producers care about -- I
get email just about every day asking how to make a favicon appear in
my software. And I always wish I could say that there's a way to
specify it in the feed.
I would favor
Henry Story wrote:
On 26 Jan 2005, at 15:03, Sam Ruby wrote:
[...]
But, now lets examine the statement proposed in
PaceAttributeNamespace. It essentially alerts producers of something
that that they need to be aware of. Now a quesion: what do they need
do different with the knowledge that the
Henri Sivonen wrote:
On Jan 26, 2005, at 23:46, Tim Bray wrote:
On Jan 26, 2005, at 1:31 PM, Henri Sivonen wrote:
But if you can always substitute type='TEXT' with type='XHTML' but
not the other way round, what's the point of having type='TEXT' in
the spec?
With type='TEXT' you know it's not
Robert Sayre wrote:
* 3.5.1 rel Attribute
Why are the only values defined alternate and related? I have
implemented via for a long time on my personal weblog and some
aggregators have even implemented support for it. I consider it to be
quite useful.
Write a Pace. I would support it.
Yes, please.
Martin Duerst wrote:
At 01:51 05/01/26, Asbjn Ulsberg wrote:
On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby [EMAIL PROTECTED]
wrote:
2. Why MUST a feed point to an alternate version. [...]
I'm -1 on removing this restriction.
I thought we came to a sort of consensus that the link
On Thu, 27 Jan 2005, Henri Sivonen wrote:
On Jan 26, 2005, at 23:40, Lucas Gonze wrote:
XHTML doesn't have styling elements like font, HTML does.
Both XHTML 1.0 Transitional and HTML 4.01 Transitional have font. Neither
XHTML 1.0 Strict nor HTML 4.01 Strict has font.
Then my point is moot as long
Sam Ruby wrote:
The feedvalidator currently declares content served as text/plain as
invalid. I would very much like to keep this check, for a number of
reasons.
What I am saying is
that the Atom spec should allow consumers enough leeway to process such
resources as non-feed (specifically, I
Tim Bray wrote:
On Jan 26, 2005, at 5:54 PM, Brent Simmons wrote:
I agree with that. It's something many feed producers care about -- I
get email just about every day asking how to make a favicon appear in
my software. And I always wish I could say that there's a way to
specify it in the feed.
On Jan 26, 2005, at 7:25 PM, Sam Ruby wrote:
Tim Bray wrote:
On Jan 26, 2005, at 5:54 PM, Brent Simmons wrote:
I agree with that. It's something many feed producers care about --
I get email just about every day asking how to make a favicon appear
in my software. And I always wish I could say
On Jan 26, 2005, at 7:25 PM, Sam Ruby wrote:
http://lists.w3.org/Archives/Public/www-html/2003Jun/0132.html
For quite some time, my XHTML has contained the following:
link rel=shortcut icon href=/favicon.ico/
Question: would it be of value to people like Graham and Brent if we
were to
On 27/1/05 3:38 PM, Sam Ruby [EMAIL PROTECTED] wrote:
atom:@rel doesn't allow for multiple space delimited values.
e.
http://lists.w3.org/Archives/Public/www-html/2003Jun/0133.html
agreed, a single term @rel value is preferred.
the shortcut icon thing is borked ... the linked favicon is
33 matches
Mail list logo
