Thursday, March 17, 2005, 5:46:39 AM, Antone Roundy wrote:
b) disallow attributes on the xhtml:div wrapper.
...
I imagine this is what you meant by b), but just to be sure, I'd vote
for d) disallow attributes other than namespace declarations on the
xhtml:div wrapper.
Yes, namespace
Thursday, March 17, 2005, 6:38:18 AM, you wrote:
Mildly put, I was never a big fan of the xhtml:div wrapper.
But if xml:lang is disallowed on the xhtml:div wrapper, this
makes even less sense to me. If Atom processors can handle
(i.e. correctly inherit) xml:lang from atom: elements into
David Powell wrote:
I think that there is a risk of interoperability problems if we don't
state which attributes are allowed on the xhtml:div wrapper.
As the xhtml:div wrapper is not part of the content: is it allowed to
contain XHTML attributes such as class and style?
I assume that if
Martin Duerst wrote:
Mildly put, I was never a big fan of the xhtml:div wrapper.
But if xml:lang is disallowed on the xhtml:div wrapper, this
makes even less sense to me. If Atom processors can handle
(i.e. correctly inherit) xml:lang from atom: elements into
the xhtml: elements as they are
On Thursday, March 17, 2005, at 03:21 AM, Thomas Broyer wrote:
Anyway, the -06 spec says XHTML is used in its basic flavor (and
that's
good! applause/), not allowing inline styles (but still the class
attribute) nor the script element.
First, just curious--did we discuss which flavor of XHTML
Antone Roundy wrote:
Second, looking at http://www.w3.org/TR/2000/REC-xhtml-basic-20001219/,
I see that the style ELEMENT is not supported, but it doesn't say that
the style ATTRIBUTE is not supported.
That's right, you have to go through the (not much readable, due to
XHTMLMOD) DTD, which
On Thursday, March 17, 2005, at 09:21 AM, Thomas Broyer wrote:
Antone Roundy wrote:
Second, looking at
http://www.w3.org/TR/2000/REC-xhtml-basic-20001219/,
I see that the style ELEMENT is not supported, but it doesn't say that
the style ATTRIBUTE is not supported.
That's right, you have to go
On Mar 16, 2005, at 10:38 PM, Martin Duerst wrote:
But if xml:lang is disallowed on the xhtml:div wrapper, this
makes even less sense to me. If Atom processors can handle
(i.e. correctly inherit) xml:lang from atom: elements into
the xhtml: elements as they are required to, I don't see
why they
Tim Bray wrote:
On Mar 16, 2005, at 10:38 PM, Martin Duerst wrote:
But if xml:lang is disallowed on the xhtml:div wrapper, this
makes even less sense to me. If Atom processors can handle
(i.e. correctly inherit) xml:lang from atom: elements into
the xhtml: elements as they are required to, I don't
On Mar 17, 2005, at 1:08 AM, David Powell wrote:
But, I think that we should disallow xhtml attributes on the
xhtml:div
-1, unless you can provide actual real examples of actual real problems
that this prevents. --Tim
Tim Bray wrote:
On Mar 17, 2005, at 1:08 AM, David Powell wrote:
But, I think that we should disallow xhtml attributes on the
xhtml:div
-1, unless you can provide actual real examples of actual real problems
that this prevents. --Tim
The underlying issue here (afaik) is that we've been told that
On Thursday, March 17, 2005, at 10:18 AM, Tim Bray wrote:
On Mar 17, 2005, at 1:08 AM, David Powell wrote:
But, I think that we should disallow xhtml attributes on the
xhtml:div
-1, unless you can provide actual real examples of actual real
problems that this prevents. --Tim
If we're going to
On 16 Mar 2005, at 5:13 pm, Robert Sayre wrote:
Graham wrote:
On 16 Mar 2005, at 1:03 pm, Robert Sayre wrote:
PaceHeadless. The chairs agree that both reads are reasonable, and
are ok with this divergence.
The working group aren't. Revert PaceHeadless immediately.
All of the objections concerned
Antone Roundy a écrit :
If we're going to be using a flavor of XHTML that doesn't support
@style, then this example is invalid, but perhaps the concept can be
transferred to some other attribute. This example assumes that the
XHTML namespace is already bound to the prefix x:
content
Graham wrote:
On 16 Mar 2005, at 5:13 pm, Robert Sayre wrote:
Graham wrote:
On 16 Mar 2005, at 1:03 pm, Robert Sayre wrote:
PaceHeadless. The chairs agree that both reads are reasonable, and
are ok with this divergence.
The working group aren't. Revert PaceHeadless immediately.
All of the
If you check the latest format draft
(http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-06.txt),
there are a bunch of open issues marked by the editor with [[anchor
We're going to need to sort out some of these before taking this
forward. Paul did a run-through, sent it to me,
C. Things that potentially require WG action:
[[anchor24: What if
there's a source-feed element? This is busted. We should make
author required for atom:feed and optional for atom:entry. No
inheritance co-constraints required. --R. Sayre]]
Right, this seems broken
On Thursday, March 17, 2005, at 02:58 PM, Tim Bray wrote:
[[anchor25: atom:entry elements MUST NOT
contain more than one atom:link element with a rel attribute
value
of alternate that has the same type attribute value. This
requirement predates @hreflang. Keep it? --R.
On Thursday, March 17, 2005, at 03:12 PM, Robert Sayre wrote:
C. Things that potentially require WG action:
[[anchor24: What if
there's a source-feed element? This is busted. We should make
author required for atom:feed and optional for atom:entry. No
inheritance
When did we decide to restrict XHTML content to XHTML Basic? I don't
remember this being discussed at all? Was it decided recently?
--
Dave
On Mar 17, 2005, at 2:52 PM, Danny Ayers wrote:
3.3 Date Constructs
...
Personally I don't think the regexp really helps, it's not normative
(which regexp spec?) and not very informative (aren't they NFL
scores?). An example or two would be more use in recognising and
understanding the format(s)
Tim Bray wrote:
On Mar 17, 2005, at 2:52 PM, Danny Ayers wrote:
Personally I don't think the regexp really helps, it's not normative
(which regexp spec?) and not very informative (aren't they NFL
scores?). An example or two would be more use in recognising and
understanding the format(s) being
On 17 Mar 2005, at 9:58 pm, Tim Bray wrote:
[[anchor7: discussion of white space]]
There were a couple of failed white-space Paces, just take this out.
I disagree - the Pace I wrote was about whitespace within content,
whereas that anchor is in a section about document syntax. I know there
On 17 Mar 2005, at 10:55 pm, Antone Roundy wrote:
atom:entry elements MUST contain exactly one atom:author element,
unless the atom:entry contains an atom:source-feed element which
contains an atom:author element, or, in an Atom Feed Document,
the atom:feed element contains an
Graham wrote:
I disagree - the Pace I wrote was about whitespace within content,
whereas that anchor is in a section about document syntax. I know there
are RSS users who think thinks like rel= alternate are acceptable.
Some discussion of this would be useful.
Write something down. I can't
On Mar 17, 2005, at 3:46 PM, Graham wrote:
On 17 Mar 2005, at 9:58 pm, Tim Bray wrote:
[[anchor7: discussion of white space]]
There were a couple of failed white-space Paces, just take this out.
I disagree - the Pace I wrote was about whitespace within content,
whereas that anchor is in a
EDITORIAL:
There are a couple of places where we use uri in the markup,
specifically the atom:uri element (3.2.2) and the uri attribute of
atom:generator (4.2.5).
In both cases they're not actually URIs, they're IRIs, so the name is
WRONG, except for nobody knows what an IRI is so renaming
On 17 Mar 2005, at 11:13 pm, Tim Bray wrote:
OSorry, this was discussed a lot and the regex has massive support.
Having said that...
Pardon? I remember the concept of three-way compatibility being
popular. The only archived discussion I can find of the regex is Norm
and Robert proposing it,
Tim Bray wrote:
EDITORIAL:
There are a couple of places where we use uri in the markup,
specifically the atom:uri element (3.2.2) and the uri attribute of
atom:generator (4.2.5).
In both cases they're not actually URIs, they're IRIs, so the name is
WRONG,
Keeping the name atom:uri is exactly
On 18/3/05 10:13 AM, Tim Bray [EMAIL PROTECTED] wrote:
Personally I don't think the regexp really helps, it's not normative
(which regexp spec?) and not very informative (aren't they NFL
scores?). An example or two would be more use in recognising and
understanding the format(s) being
EDITORIAL:
RFC3987, section 5.1 reads
Applications using IRIs as identity tokens with no relationship to a
protocol MUST use the Simple String Comparison...
Should we call this out?
Robert Sayre
Tim Bray wrote:
EDITORIAL:
There are a couple of places where we use uri in the markup,
specifically the atom:uri element (3.2.2) and the uri attribute of
atom:generator (4.2.5).
In both cases they're not actually URIs, they're IRIs, so the name is
WRONG, except for nobody knows what an IRI is
On Mar 17, 2005, at 00:57, David Powell wrote:
c) disallow XHTML attributes on the xhtml:div wrapper, but
allow xml:lang.
If you allow declaring the language, why do you disallow declaring the
dominant writing direction (dir)? Shouldn't they be allowed or
disallowed together?
d) Get rid
Henri Sivonen wrote:
On Mar 17, 2005, at 00:57, David Powell wrote:
c) disallow XHTML attributes on the xhtml:div wrapper, but
allow xml:lang.
If you allow declaring the language, why do you disallow declaring the
dominant writing direction (dir)? Shouldn't they be allowed or
disallowed
Tim Bray wrote:
EDITORIAL:
There are a couple of places where we use uri in the markup,
specifically the atom:uri element (3.2.2) and the uri attribute of
atom:generator (4.2.5).
In both cases they're not actually URIs, they're IRIs, so the name is
WRONG, except for nobody knows what an IRI is
35 matches
Mail list logo
