+1
We are going to have a registration process, so undoubtably this will be
registered anyway, but we might as well as include it in the initial batch.
- Sam Ruby
for basic clients to scan entries in the
Current implementations stuff the whole entry in
there
See:
http://www.imc.org/atom-protocol/mail-archive/msg00442.html
Wouldn't the same objection apply here?
- Sam Ruby
Henri Sivonen wrote:
On Feb 9, 2005, at 15:28, Sam Ruby wrote:
Here's the key question. Consider the following XML fragment:
summary type='XHTML'div xmlns='http://www.w3.org/1999/xhtml'Hey,
this is my space, if I want to run a picture of a chair I can. And
its a emnice/em chair./div/summary
Julian Reschke wrote:
Sam Ruby wrote:
That's what I want to change. I've updated the Pace to make this
clearer. I replaced the abstract completely, and added one sentence
to the proposal.
New abstract:
Given that common practice is to include this element, making it
mandatory makes things
Julian Reschke wrote:
Sam Ruby wrote:
That is consistent with your prior statement that you don't believe
that implementation issues should affect the format:
http://www.imc.org/atom-syntax/mail-archive/msg12699.html
What I said is that very *specific* implementation issue shouldn't
affect
enough?
- Sam Ruby
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
/PaceXhtmlNamespaceDiv)
I have just updated the Pace to remove from the abstract text which is
no longer reflected in the proposal.
- Sam Ruby
the elements in XHTML may
also be appropriate.
- Sam Ruby
NOT.
- Sam Ruby
over time to see multiple such
wrappings.
-Sam Ruby
is POSTed to a blog, is the div part of the content?
- Sam Ruby
Anne van Kesteren wrote:
Sam Ruby wrote:
Ok, now that I'm thinking about this more, I'm changing my initial
+0 to +1. This just makes sense. There does need to be a container
for the XHTML and div is a solid, logical choice. I don't think it
should matter where the xmlns is declared... any
will read anything into the order.
- Sam Ruby
editorial at all, then. I guess I'd have to see some more
spec text, then. I'm not sure what Mark is proposing.
I missed that too... otherwise I would have simply put this Pace in the
Recommended for Closure list.
-1 on this Pace until section 6 is flushed out.
- Sam Ruby
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.
2) Tim (who uses string concatenation) will have to do more work.
3) More feeds will be harder to read (that's why I asked
.
- Sam Ruby
Bob Wyman wrote:
Sam Ruby wrote:
If you produce feeds that contain multiple entries with the same
id, there will be people who misunderstand such documents.
So what? If they initially misunderstand, they will eventually learn
how to do it properly.
It is quite possible that they outnumber you
Mark Nottingham wrote:
I tried to post this to the Wiki, but it said I wasn't allowed to. Hmm.
I have a spam throttle that limits the number of unique pages a person
who is not logged in can edit per hour. I'll send you login info.
- Sam Ruby
this does mean is that the feedvalidator either needs to be updated
when new versions of Atom come out, or become increasingly irrelevant
and obsolete as new validators assume this role (possibly something as
simple as a RelaxNG schema).
- Sam Ruby
of the specification.
RSS 0.9x (including 2.0) is evidence that the former is possible (I can
cite some minor incompatibilities, but these are merely exceptions that
prove the rule). I do believe that the latter is also possible.
Without ever changing the namespace.
- Sam Ruby
of
this, but not all of it. Do we need something more?
That is what I am aiming for.
I put some placeholder text at the bottom of PaceRemoveVersionAttr, but
it definately needs to be expanded/improved.
- Sam Ruby
/ongoing.atom
No, it is not a registered uri scheme, but it seems to be a defacto
standard.
- Sam Ruby
P.S. w.r.t. the version attribute, I still believe that YAGNI. But if
it is to remain, I hope that the final version is mercifully short.
.
In place of a path, I see what appears to be a timestamp. Can somebody
cite a reference which permits such uris?
- Sam Ruby
the Wiki as the forum for sharing proposals
for extensions once the core syntax has been finalized?
Sounds like a good idea to me. Mind you, it's Sam's wiki :) -Tim
Heh, good point ;-) ... Sam? Ultimately it is your call.
Go4it.
- Sam Ruby
to subscribe
to PlanetApache.org (with whom I have a modicum of trust), but not to
mymonkeysbutt.net (with which I presumably don't).
- Sam Ruby
implementations when it comes to
duplicate detection.
+1
It will be actively harmful to Atom's success if the standard is defined
in such a way that is no realistic expectation that it will be followed.
- Sam Ruby
Robert, can you take a stab at updating section 1.2 for this Pace?
I'll also note that this example is not valid. It does not contain
either a summary or content element.
One thing to consider is to do like what was done in Atom 0.3 [1]:
provide both a minimal and maximal example.
- Sam Ruby
Robert Sayre wrote:
Sam Ruby wrote:
Robert Sayre wrote:
* 4.21 The atom:info Element -- If it's not considered meaningful
for processors, why does there need to be a standard element for it?
At the very least, some sort of information about its semantics
should be documented. My preference
Paraphrasing Tim [1] I'm definitely -1 on losing 3.5.1, the
canonicalization warning is a hard-won compromise and seems to cause
no-one any pain.
We discussed this at extreme length, and no new arguments have been
brought forward. Rough consensus does not mean absolute consensus.
- Sam Ruby
Robert Sayre wrote:
Sam Ruby wrote:
Robert, can you take a stab at updating section 1.2 for this Pace?
Yes, but the Pace is complete without it.
It would be much easier to discuss the pace with an example.
I gather that a format-05 compatible feed, thus:
feed
entry
head.../head
, then atom:info should be tossed.
We should either explicitly allow application/xml in section 2, or
remove this element. I'm not sure which I prefer.
- Sam Ruby
[1] http://www.w3.org/TR/REC-xml/#sec-guessing-with-ext-info
Julian Reschke wrote:
Robert Sayre wrote:
Tim Bray wrote:
On Jan 30, 2005, at 12:09 PM, Robert Sayre wrote:
We should either explicitly allow application/xml in section 2, or
remove this element. I'm not sure which I prefer.
atom:info is useful during transformations. Tossing atom:info will
with
prefixes:
atomTitle type=XHTML
div xmlns=http://www.w3.org/1999/xhtml;Less: em lt; /em/div
/atomTitle
The above is similar to your example, but not _identical_ to your
example, given the current spec.
- Sam Ruby
example.
- Sam Ruby
a SAX input stream.
Some XSLT constructs (example: sort) can effectively render this moot,
but overall Xalan tries really, really hard to stream.
- Sam Ruby
as a DOM or as a string), everything is via pipelined SAX
processing.
An example of an application which leverages such an approach (as well
as sophisticated caching) can be found at http://cocoon.apache.org/2.0/
- Sam Ruby
the
definition of type='XHTML' consistent (there are other types available,
after all) or requiring a summary element to be present if the first
child element of atom:content with type='XHTML' is not an xhtml:div.
- Sam Ruby
Julian Reschke wrote:
Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
Consumers don't want full web pages (complete with html head and titles)
as summaries, they want something that they can
Henri Sivonen wrote:
On Jan 28, 2005, at 20:21, Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
I, for one, use gnu.xml.pipeline.NSFilter for ensuring the namespace
correctness in my RSS feed
Danny Ayers wrote:
On Wed, 26 Jan 2005 21:39:23 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
PaceAttributeNamespace does not do that. All it says is is that a given
namespace may be used. For what purpose such a statement is made is
entirely unclear.
Ok, maybe a little more explanation is needed
.
- Sam Ruby
is nothing. Meaning that
this particular statement is not needed. Again, no issue with the
mapping. No issue with describing the mapping alongside with the actual
mapping.
- Sam Ruby
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
like having a very conservative default of
TEXT. And then for those who wish to get more adventurous, there are
two choices: XHTML (compact, clear, but must be well formed), and double
escaped HTML (verbose, error prone, but can handle arbitrary content).
- Sam Ruby
.
- Sam Ruby
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
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 register this rel value for Atom feeds?
- Sam Ruby
. Does that mean that a
Simple Extension can't use xml:lang? Does a formerly Simple Extension
become a Structured Extension if it requires internationalization?
I work best with specific example. How should wfw:comment be handled?
- Sam Ruby
David Powell wrote:
(I couldn't find a list of RSS2.0 extensions).
http://blogs.law.harvard.edu/tech/directory/5/specifications/rss20ModulesNamespaces
- Sam Ruby
Norman Walsh wrote:
I'd feel more confident about my RELAX NG grammar if I could feed
more than my own two or three test cases through it.
What we have is here:
http://intertwingly.net/wiki/pie/ConformanceTests
If anybody knows of more, please add it to the list.
- Sam Ruby
/feed_playlists_versus_feed_urls
The only additional requirement I can see is that it might make sense to
have a separate mime type for feeds which only reference other feeds,
and feeds which contain content.
- Sam Ruby
Norman Walsh wrote:
2. Why MUST a feed point to an alternate version. What if the feed is all
I publish?
Deja vu:
http://www.imc.org/atom-syntax/mail-archive/msg08836.html
I'm -1 on removing this restriction.
- Sam Ruby
Graham wrote:
On 12 Jan 2005, at 9:54 pm, Sam Ruby wrote:
2. Why MUST a feed point to an alternate version. What if the feed is
all
I publish?
Deja vu:
http://www.imc.org/atom-syntax/mail-archive/msg08836.html
I'm -1 on removing this restriction.
I'm +1 on removing it, and given the number
lesson. Bad Sam.
Every version of RSS has this as a mandatory element. Every last one of
them.
- Sam Ruby
Graham wrote:
On 13 Jan 2005, at 2:39 am, Sam Ruby wrote:
Every version of RSS has this as a mandatory element. Every last one
of them.
Except RSS 2.0:
An item may also be complete in itself, if so, the description contains
the text (entity-encoded HTML is allowed; see examples), and the link
for
dicussion:
PaceAltExtensibilityAndVersioning
PaceExtendingAtom
PaceExtensibilityAndVersioning
PaceExtensibilityAndVersioningNoScenarios
PaceExtensionNamespace
PaceMinimalEntryVersioning
PaceMustUnderstandElement
PacePropertyDesign
PaceSupersede
- Sam Ruby
[Reissuing with a corrected subject line]
Sam Ruby wrote:
The biggest open issue (at least on the format side, and potentially on
the protocol side) is extensibility. I would like to see us get
*something* into the drafts; even if imperfect, it can be incrementally
improved upon.
So, I'm
element or attribute to any feeds that
employ an extension.
Meanwhile, it would not be harmful to mention this one element or
attribute (anybody have a preference) in the specification.
- Sam Ruby
[1] http://www.w3.org/TR/grddl/
101 - 159 of 159 matches
Mail list logo
