I detect that a lot of opposition to atom:modified comes from the fact
that it is a REQUIRED element and that many of the publishers actually
putting it in the feed and paying for the bandwidth don't intend using
it frequently?
Would it help if we said that if the atom:modified element is
Saturday, May 21, 2005, 3:28:26 PM, Robert Sayre wrote:
This line:
Their atom:updated timestamps SHOULD be different
Ah. I misread their orders, thinking I was only to include the first
sentence. You're 100% right. Note that this does not mean I'm in favor
of atom:modified. Versioning
Friday, May 20, 2005, 3:09:07 PM, Robert Sayre wrote:
I'm not dismissing them. I'm saying they should use an extension,
which they'll be needing anyway.
The important thing is that we should make sure that they can use an
extension to do this. The current wording for Person construct might
Friday, May 20, 2005, 8:02:49 PM, Paul Hoffman wrote:
Does the WG want to be able to open up new topics, or re-open old
topics with a twist? If so, do we all agree to the delay in
publication that comes with that?
What would the minimum delay be out of interest? 4 weeks? 6 weeks?
[reposted without so many typos and grammatical errors - reply to either]
As I was the last person to mention atom:modified, I'll refer to my
proposal as an example in this reply.
1. The datestamp is inserted by the provider. Thus it could be a lie;
this is the Internet, remember. You, the
Monday, May 16, 2005, 5:39:17 PM, Graham wrote:
On 16 May 2005, at 5:16 pm, Eric Scheid wrote:
if you want to sort by updated or published, but not for most recently
changed (even if not 'significantly')
Well yes. So? I consider atom:modified to be unfeasible anyway for
all sorts of
Monday, May 16, 2005, 12:07:23 PM, Sam Ruby wrote:
3) Perhaps version/modified need not be mandatory except in those
instances where entries with duplicate ids are present in a feed?
If we want to support the cases of aggregating multiple feeds and of
full archiving (other than by the
PaceAllowDuplicateIDs received some opposition because of its use of
atom:updated to differentiate multiple revisions of an entry [1][2][3].
I've posted a couple of Paces - basically a single a proposal, split
into two bite-size pieces:
Thomas Broyer wrote:
David Powell wrote:
I'm in favour of allowing duplicate ids. This only seems to be a
partial solution though:
Their atom:updated timestamps SHOULD be different
But what if they are not? What if I want to represent an archive of a
feed - maybe mine, maybe someone
Friday, May 6, 2005, 3:52:19 PM, Eric Scheid wrote:
On 7/5/05 12:09 AM, Graham [EMAIL PROTECTED] wrote:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MUST treat them as multiple versions of the same
entry
I don't think this changes the technical
In Section 4.2.15:
Publishers MAY change the value of this element over time.
This sentence seems pretty obvious. It could be said about atom:title,
or any of the fields. Does it have some subtle meaning that I am
missing?
--
Dave
Sunday, May 8, 2005, 9:28:08 AM, you wrote:
Robin: In my opinion, the only place an atom:copyright should appear
is at the feed level, as an assertion of ownership of the feed
document itself.
[Disregarding the name and legal meaning of the element...]
What about entry documents though,
Thursday, May 5, 2005, 11:42:22 PM, Tim Bray wrote:
-1
Irrespective of whether I agree with this or not, I think the material
belongs in an implementor's guide, not the specification. -Tim
I'm a bit uncomfortable with punting yet another issue into the
Implementor's Guide when the WG has
Friday, May 6, 2005, 5:46:59 PM, you wrote:
Some have been clamoring for a good definition of an entry.
Here is one I have thought of recently.
An Atom Entry is a resource (identified by atom:id) whose
representations
(atom:entry) describe the state of a web resource at a time
(the
Friday, April 22, 2005, 8:06:56 AM, Thomas Broyer wrote:
As some of you have already said, the problem isn't really xml:base but
the base URI.
Here's one more question: when a feed have no xml:base, it's base URI is
the URI from where is has been retrieved.
Don't forget that the
Thursday, April 21, 2005, 7:05:55 PM, you wrote:
I guess we could also use a quick survey of xml:base support in parsers,
xslt implementations, etc. if we don't already have one.
xml:base was supposed to be in XSLT 1.1, and Saxon supports it right
now.
Does XSLT 1.1 support xml:base in
Friday, April 22, 2005, 8:35:29 AM, you wrote:
On Fri, 22 Apr 2005 09:06:56 +0200, Thomas Broyer [EMAIL PROTECTED]
wrote:
As said above, the base URI problem is not only an xml:base one... and
it's not easy to solve...
Well, actually it is. It's a huge camel to digest, but the solution
Thursday, April 21, 2005, 12:32:00 AM, Robert Sayre wrote:
David Powell wrote:
I recently tried to render a bunch of Atom entries as an HTML page and
I hit a problem. I think it is probably worth mentioning now in case
any implementors hadn't noticed it:
Atom supports xml:base anywhere
Quoting Bill de hÓra [EMAIL PROTECTED]:
I think we need to update the draft and stress that (X)HTML content is
not subject to xml:base processing.
I didn't read this carefully enough when I replied earlier, I didn't see that
Robert was suggesting that xml:base shouldn't apply to (X)HTML at
Sunday, April 17, 2005, 9:47:39 AM, Henri Sivonen wrote:
DTDs and namespaces are inherently incompatible. I think the
restrictions the official DTDs place on namespace declarations should
be ignored when embedding XHTML in Atom.
I strongly agree. Namespaces are a pretty fragile technology;
I've posted a draft of PaceSourceRecs [1]. It proposes that an
informative section should be added to give some recommendations on
how to use safely use atom:source without screwing up xml:lang and
xml:base.
I'm not sure where the Informative section should go? Should it go
inline, as a
Wednesday, April 13, 2005, 7:06:09 PM, Anne van Kesteren wrote:
| Also, what do you expect feed readers to support for XHTML versions, etc.
I don't have any. I'll tailor my content to suit what the major
vendors support, just like I do with my plain old HTML today. In
practice, my feeds
The type attribute of atom:content can be a MIME media type:
4.1.3 The atom:content Element
[...]
4.1.3.1 The type attribute
[...]
[...] Failing that, it MUST be a MIME media type [RFC2045] with a
discrete top-level type (see Section 5 of [RFC2045]).
After looking at RFC2045, I wasn't
According to the RelaxNG:
atomSource =
element atom:source {
atomCommonAttributes,
(atomAuthor?
atomCategory*
atomContributor*
atomCopyright?
atomGenerator?
atomIcon?
atomId?
I'm currently experimenting with writing an XSLT stylesheet that
transforms RSS 2.0 into the same RDF/XML model that my atom2rdf
stylesheet[1] creates.
Do we have an equivalent to RSS's comments [2] element? This is a
pretty widely used feature of RSS does it deserve a link/@rel value
in Atom?
- in 6.4; extension schema allow the use of the atom namespace as child
elements of the extension. I do not recall this being discussed, but
personally am +1 to it.
Yeah, I'm ok with it too. I'm not sure why anyone would want to do it,
but the spirit of Structured Extension elements was that
Friday, April 8, 2005, 12:13:40 AM, Martin Duerst wrote:
+1 to adding these kinds of clarifications and examples to the spec!
The simplest thing would probably be to RECOMMEND that processors
resolve the base and lang values for the atom:entry and atom:feed
elements of source feed, and
I've updated my Atom to RDF/XML XSLT transform to implement draft-06.
I think that it implements everything, including:
* xml:lang and xml:base resolution
* Structured and Simple Extension constructs
* Resolving of defaulted atom:author elements.
There is an RDFS schema of the model up
I noticed another bug in the RNG. The collected RNG is missing a '?'
after atomIcon:
atomSourceFeed =
element atom:source-feed {
atomCommonAttributes,
( atomTitle
atomUpdated
atomLink+
atomIcon
should be:
atomSourceFeed =
element
In other words, the presence of an element with the namespace IRI
http://www.w3.org/2000/09/xmldsig#;
Namespace IRI, is that a find-replace-o?
--
Dave
Friday, March 18, 2005, 7:08:32 PM, Bjoern Hoehrmann wrote:
uri -- wrong
iri -- unknown to many users
web -- misleading to many users
I suggest confronting users with something unknown is better than
misleading them.
How about something with less meaning attached to it, such as
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
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
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 these attributes are
Thursday, March 17, 2005, 12:25:29 AM, Tim Bray wrote:
On Mar 16, 2005, at 2:42 PM, David Powell wrote:
Any element in an Atom Document MAY have an xml:base attribute.
Any element in an Atom Document MAY have an xml:lang attribute
Not all XHTML elements can legally carry an xml:lang
The purpose of the Pace isn't to ensure that databases don't lose language
tags:
it is to licence databases and other models to not preserve language tags
where
they are not meaningful.
Then, erm, why doesn't it say that?
I was tired. Sorry for the confusion.
I will try to rephrase it
Quoting Karl Dubost [EMAIL PROTECTED]:
Implementations MUST preserve the language context of language
sensitive constructs.
[...]
If it's about stocking information in a database and that this
information is not lost, I don't see how it's related to Atom. It's a
separate design issue.
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
I've posted PaceLangSpecific. It allows the use of xml:lang, but
clarifies which properties are language specific.
== Abstract ==
Allow xml:lang anywhere, but restrict its effects to specific elements
so that it is clear when implementations must preserve the language
context.
== Status ==
Sunday, February 6, 2005, 3:10:23 AM, you wrote:
On 6/2/05 4:27 AM, David Powell [EMAIL PROTECTED] wrote:
Although we could keep the model we have (let's call it the 'mutable entries'
model), it isnt clear on a number of issues. Eg, if an old version of an
entry has some property
(I.e., I could come up with the UseLexicalOrdering extension, and
require processors to understand it to use the feed, assuming our
extensibility model supports that, which I very much hope it will).
Ok, well I am assuming that we wont have MustUnderstand extensions, therefore
The RELAX-NG in draft-05 seems to allow atom:feed to contain
anyElement - this doesn't seem to be allowed by the spec's prose - is
this a typo?
--
Dave
Tuesday, February 1, 2005, 5:18:44 AM, you wrote:
P.S. Feed Document may be somewhat misleading, because it's easy to
confuse it with Feed (which has connotations of the information
channel). I think Feed Snapshot Document or the like was once
proposed, but it was shot down. *shrug*
In
Saturday, January 29, 2005, 11:13:51 AM, you wrote:
The RDF vocabulary was just constructed ad-hoc - like I said, it is
just a proof of concept. It uses a separate namespace to Atom and
defines some new terms, which solves any problems with non-unique
attributes.
That makes sense.
Friday, January 28, 2005, 9:27:11 PM, you wrote:
Sorry, that version created duplicate rdf:nodeIDs. I've fixed it now,
the new version is 9826 bytes.
--
Dave
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.
If RDF users have to transform the content in order to interpret it as
RDF/XML (which they do), then they might as well transform it to a
Tuesday, January 25, 2005, 5:30:51 AM, you wrote:
At 10:00 05/01/25, Sascha Carlin wrote:
Tim Bray wrote:
Not yet taken up by the WG, depends on the discussion that comes with
this call. Same rules as all the others: there has to be a positive WG
consensus that each adds to the base
Monday, January 17, 2005, 5:06:47 AM, you wrote:
I think this proposal throws out the baby with the bathwater.
I don't see any reason to introduce an atom:language element;
xml:lang can serve exactly the same purpose. If you want to
reduce the effect on performance/DBs, there are the
PaceExtensionConstruct hopes to provide a basis for a mapping Atom to
models such as RDF [1], ER, and OO. I'm currently doing some work to see
whether there is anything in Atom that makes this unnecessarily
difficult.
I think that Atom's use of xml:lang is likely to be a significant
problem to
I've just updated this proposal thanks to some of the feedback that I
received. There is a change history at the end of the document.
http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct
--
Dave
The semantics of atom:contributor weren't obvious to me. Is this
correct:
atom:feed/atom:head/atom:author is a syntactic default for all entries
that are missing an author.
atom:feed/atom:head/atom:contributor is a set of regular contributors
and authors of a feed, which may or may not have
I think that PaceUriReferences can be closed. It seems to have been
incorporated into the -04 draft as part of the Update URI terms for
2396bis revision.
http://www.intertwingly.net/wiki/pie/PaceUriReferences
--
Dave
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
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
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
Saturday, January 8, 2005, 9:59:12 AM, you wrote:
Say your system is aggregating material from two sensors, and you get
the following, one from each:
entry
idhttp://123/id
date2005-02-02/date
geo:x10.1/geo:x
geo:y57.3/geo:y
/entry
entry
idhttp://123/id
I'd say that the most useful basic features of RDF are:
1) Property names are namespaced for extensibility.
2) Important entities can be assigned global identifiers so that they
can be referred to externally.
3) Statements are properties of an object rather than being simple
name/value
Friday, January 7, 2005, 9:28:33 PM, you wrote:
Another example might be a property such as ex:rating, intended to
provide slashdot-style ratings specific to the community of readers of
that feed. If those entries are republished, then the original ratings
shouldn't be republished in the
101 - 160 of 160 matches
Mail list logo
