Tim Bray wrote:
On Jan 11, 2005, at 5:07 PM, Graham wrote:
is mixing layers quite a bit. The HTML markup must appear as text [in
the infoset], such that it appears escaped in the XML source.
Good idea I think... rather than the current convolutions around
escaping and levels, talk about what
1. Is xml:base processing applied to the schema attribute of a Category
Construct?
2. Why MUST a feed point to an alternate version. What if the feed is all
I publish?
3. 4.2.2 says
atom:head elements MUST NOT contain more than one atom:link element
with a rel attribute value of
| 1. Introduction
|
|Atom is an XML-based document format intended to allow lists of
s/intended to allow/which describes/
|related information, known as feeds. Feeds are composed of a
s/, known/ known/
|[[ more motivation / design principles ]]
Recent mail on the list suggests
Norman Walsh wrote:
...
|Any element in an Atom Document MAY have an xml:base attribute. XML
|Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any
|relative reference [RFC2396bis] present in an Atom Document. This
s/relative reference/relative URI reference/
Relative
/ Norman Walsh [EMAIL PROTECTED] was heard to say:
| 4. 5.14 says
|
|If an atom:entry is copied into one feed from another feed, then the
|atom:head element of the source feed SHOULD be inserted into the
|atom:entry unless the entry, as copied, already contains an atom:head...
|
|
Norman Walsh wrote:
1. Is xml:base processing applied to the schema attribute of a Category
Construct?
It's a URI, rather a URI reference. From 2396bis:
URI-reference = URI / relative-ref
I guess this means we should put the no relative references language
here as well.
2. Why MUST a feed
On Jan 12, 2005, at 8:57 AM, Robert Sayre wrote:
Or, for that matter, different titles and URIs. I think we should drop
the restriction.
Any time you drop a restriction, you're adding complexity to
implementations. Might be worthwhile, but should be born in mind. -Tim
On Wednesday, January 12, 2005, at 09:57 AM, Robert Sayre wrote:
3. 4.2.2 says
atom:head elements MUST NOT contain more than one atom:link element
with a rel attribute value of alternate that has the same type
attribute value.
What if the atom:link elments have different hreflang values?
Robert Sayre wrote:
Norman Walsh wrote:
2. Why MUST a feed point to an alternate version. What if the feed is all
I publish?
I don't know. I say we drop it.
+1.
3. 4.2.2 says
atom:head elements MUST NOT contain more than one atom:link element
with a rel attribute value of alternate that
Only lightly tested, and still a work in progress, but for curious...
atom.rnc
Description: Binary data
Be seeing you,
norm
--
Norman Walsh [EMAIL PROTECTED] | Simplification good! Oversimplification
I've just posted PaceExtensionConstruct. As it is an extensibility
Pace, it would be good if we could schedule it for discussion with the
others.
http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct
--
Dave
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
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 of people who've
On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby [EMAIL PROTECTED]
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 think this goes along with the alternate entry discussion which ended
http://www.intertwingly.net/wiki/pie/PaceMinimalEntryVersioning
Multiple instances or versions of the same entry MAY appear in a feed,
index, or archive.
I'm in favor of this--it's easy enough to imagine uses for it (like a
feed showing the history of a particular entry).
Consumers MAY choose
http://www.intertwingly.net/wiki/pie/PaceMustUnderstandElement
Any Atom document MAY contain a single atom:must-understand element,
which, if it appears, MUST be the first child element of the document
element.
I think we need to add language stating that aggregators aggregating
entries
http://www.intertwingly.net/wiki/pie/PacePropertyDesign
* Simple
The content of the element MUST be CDATA, and have no attributes.
Perhaps character data instead of CDATA would be better, as a quick
reading might be taken to imply that the content must be in ![CDATA[
]].
* RDF Resource
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 of
I never finished this Pace, and it can be considered withdrawn.
Robert Sayre
Antone Roundy wrote:
http://www.intertwingly.net/wiki/pie/PacePropertyDesign
* Simple
The content of the element MUST be CDATA, and have no attributes.
Perhaps character data instead of CDATA would be better, as a
On Wednesday, January 12, 2005, at 04:53 PM, Sam Ruby wrote:
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
David Powell wrote:
I've just posted PaceExtensionConstruct. As it is an extensibility
Pace, it would be good if we could schedule it for discussion with the
others.
http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct
I like this one. I think the atom:notation attribute is useless,
On Jan 12, 2005, at 3:25 PM, Antone Roundy wrote:
http://www.intertwingly.net/wiki/pie/PaceMustUnderstandElement
Any Atom document MAY contain a single atom:must-understand element,
which, if it appears, MUST be the first child element of the document
element.
I think we need to add language
Wednesday, January 12, 2005, 10:51:58 PM, you wrote:
The root element of a Structured Extension construct MAY have
attributes, it MAY contain well-formed XML content, or it MAY be
empty.
It took me a minute to realize that the content of a structured
extension element could be a text
Thursday, January 13, 2005, 12:25:16 AM, you wrote:
David Powell wrote:
I've just posted PaceExtensionConstruct. As it is an extensibility
Pace, it would be good if we could schedule it for discussion with the
others.
http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct
I like
On Wednesday, January 12, 2005, at 05:27 PM, David Powell wrote:
Wednesday, January 12, 2005, 10:51:58 PM, you wrote:
The root element of a Structured Extension construct MAY have
attributes, it MAY contain well-formed XML content, or it MAY be
empty.
It took me a minute to realize that the
David Powell wrote:
I think it would be bad to have two different mappings for the same
extension depending on whether the instance happenned to contain any
tags.
I'm not sure why you would have two different mappings. Wouldn't it just
be an XML property every time?
I can't think of a use
On 13 Jan 2005, at 12:03 am, Antone Roundy wrote:
Every piece of running code, for all versions of RSS and Atom, expect
this data to be present.
...except CaRP and Grouper. Any others?
Shrook and NetNewsWire?
I believe Sam needs to go sit in the corner until he's learnt his
lesson. Bad Sam.
Thursday, January 13, 2005, 12:57:47 AM, you wrote:
On 12 Jan 2005, at 9:19 pm, David Powell wrote:
I've just posted PaceExtensionConstruct. As it is an extensibility
Pace, it would be good if we could schedule it for discussion with the
others.
Me likey. Except:
The root element of
Graham wrote:
On 13 Jan 2005, at 12:03 am, Antone Roundy wrote:
Every piece of running code, for all versions of RSS and Atom, expect
this data to be present.
...except CaRP and Grouper. Any others?
Shrook and NetNewsWire?
I believe Sam needs to go sit in the corner until he's learnt his
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
Sam Ruby wrote:
http://blogs.law.harvard.edu/tech/rss#requiredChannelElements
OK, Sam has swayed me.
If there are masses of publishers eager to do away with that
restriction, they will. And someone will come back and change the spec
to reflect reality. However, that link element often just
31 matches
Mail list logo
