Tuesday, February 8, 2005, 12:44:26 AM, you wrote:
PaceLangSpecific
+1, but also needed for atom:generator
hmmm ... if we have xml:lang on content, we are going to also need
@hreflang for content src=... /, because while some types of referenced
content can have the language attached, at
Henry Story wrote:
If you just want to stick to syntax, then please leave the pace
as it is. Don't try to impose a model through syntax and then
argue that people can't argue about the model that you are
surreptitiously trying to introduce.
Henry, I have no idea what you are talking about.
cheers
On Feb 7, 2005, at 23:21, Sam Ruby wrote:
1) Graham (who uses proper XML tools) will have to do more work.
Which tools? How much more? One loop more?
(FWIW, I do not consider Apple's Core Foundation XML parser a proper
XML tool.)
2) Tim (who uses string concatenation) will have to do more
On Feb 8, 2005, at 07:03, Henri Sivonen wrote:
On Feb 8, 2005, at 01:55, Sam Ruby wrote:
Can I get one of you three to mock up what Tim's feed should look
like?
a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04'
version='draft-ietf-atompub-format-04 : do not deploy'
On Feb 7, 2005, at 22:58, Sam Ruby wrote:
If you are opposed to this pace, then what div element?
If the pace does not get through, it is still permissible to put a div
in there as part of the content. In fact, either way it is permissible
to add meaningless extra divs, since a div can nest in a
On Tue, 08 Feb 2005 10:40:43 +, Bill de hÓra [EMAIL PROTECTED] wrote:
Henry Story wrote:
If you just want to stick to syntax, then please leave the pace
as it is. Don't try to impose a model through syntax and then
argue that people can't argue about the model that you are
On Feb 8, 2005, at 10:43, David Powell wrote:
text/plain can have a Content-Language header though - is that
compatible with
xml:lang?
For practical purposes, yes. In theory, the semantics are different.
xml:lang specifies the language of the content but Content-Language
describes the language
Robert Sayre wrote:
Bill de hÓra wrote:
The problem is that switching on the content of an element/attribute
is Atom's get out of jail card wrt extensibility. It is the default
Atom extensibility model, as it's the only game we have to play that
doesn't involve screwing about with the meaning
Sam Ruby wrote:
Bill de hÓra wrote:
Sam Ruby wrote:
If this Pace is not adopted, the following predictions can be made:
1) Graham (who uses proper XML tools) will have to do more work.
I'd like to see a concrete example where this is a problem. As far as I
can tell, the content construct itself
Julian Reschke wrote:
Sam Ruby wrote:
Julian Reschke wrote:
Anne van Kesteren wrote:
Henri Sivonen wrote:
-1 on PaceXhtmlNamespaceDiv
-1 from me as well. It is hack which might be useful for publishing
systems (and perhaps aggregators) who do not use the right tools to
generate a valid Atom file
James M Snell wrote:
My preference would be a link based alternative.
feed
...
entry
...
link rel=feed href=... /
/entry
/feed
I'm tired of arguing this one, so, I'm just going to say this one
more time and leave it at that.
Linking to the feed is not an
Sam Ruby wrote:
Nothing changes for Tim, he can continue to produce the output he's
producing currently.
What Tim is syndicating does not match the content on his site. Without
this Pace, the div element would need to be considered part of the content.
What difference does this make in
On Feb 8, 2005, at 15:59, Julian Reschke wrote:
When a Text construct or atom:content's type is XHTML, require it
to have a single xhtml:div as a child, and require that div to declare
the XHTML namespace.
Am I looking at the wrong pace?
Julian Reschke wrote:
- Requiring the namespace declaration on a particular element means
(a) profiling XMLNS, (b) defeating potential space optimizations by
having the namespace declaration only once, and (c) breaks XML
toolkits that do not provide full control over where namespace
Julian Reschke wrote:
(http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1)
The spec currently says:
If the value of type is HTML, the content of the Text construct
MUST NOT contain child elements, and SHOULD be suitable for handling by
software that knows HTML.
--On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote:
Linking to the feed is not an acceptable solution. It must be
possible to embed feed metadata in an entry in a feed and in an Entry
document.
+1
The feed document *must* be standalone. Everything required to
Well, I ain't gonna argue the point, but I'm going to stick by the
assertion that feeder/head is ugly. Any use of this stuff I plan to
make can live equally well with either approach.
- James M Snell
Walter Underwood wrote:
--On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman
[EMAIL
On 8 Feb 2005, at 12:14 am, Eric Scheid wrote:
PaceArchiveDocument
-1
this looks like a backdoor to feeds in feeds.
-1, agreed.
Graham
-1 on the regex. It's completely unreadable and hides whatever
additional constraints it adds. Write those down in English please.
Graham
Sam Ruby wrote:
Julian Reschke wrote:
(http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1)
The spec currently says:
If the value of type is HTML, the content of the Text construct
MUST NOT contain child elements, and SHOULD be suitable for handling
by software
/ Graham [EMAIL PROTECTED] was heard to say:
| -1 on the regex. It's completely
| unreadable and hides whatever
| additional constraints it adds. Write
| those down in English please.
Well, how about English and the regex? I'm worrying about
interoperability here. There's considerable pressure to
At 23:36 05/02/08, Julian Reschke wrote:
Shouldn't we at least give content producers the hint that producing
XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here)
I'd be very much in favor of that. The first step is to order the sections
so that XHTML comes first. I
At 22:59 05/02/08, Julian Reschke wrote:
http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv
I have looked at this pace only just very recently, after
following the discussion. So I first want to make sure I
get the current status of this proposal right.
As I currently read it, it does:
1)
On 9/2/05 3:39 PM, Martin Duerst [EMAIL PROTECTED] wrote:
Note: It is important to make sure that correct namespace declarations
for XHTML are present. One way to do this is by using an xhtml:div
element as the content of the atom:content element and specifying
the XHTML namespace on that
24 matches
Mail list logo
