Posted PaceLangSpecific
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 ==
Open
Author: DavidPowell
== Rationale ==
xml:lang can appear anywhere and specifies a language for all children
of its containing element. This is simple enough in the context of an
XML document, but in the context of any other model, language tags
need to be explicitly preserved for every property of each entry and
feed.
Many Atom implementations will use RDBMs or object-oriented
implementations, rather than XML DOMs to model and store atom content
internally. In a RDBMs model, each language sensitive field will
require an extra database column. It is clear that some fields, such
as atom:updated, are not language dependant, while others such as
atom:content are. Some fields are grey areas.
This proposal improves interoperability by ensuring that xml:lang is
processed consistently by different implementations. It improves
efficiency by allowing implementations to safely discard the language
context for non-language specific fields.
== Proposal ==
In section 2, replace:
{{{ Any element in an Atom Document MAY have an xml:lang attribute,
whose content indicates the natural language of the element's content.
Requirements regarding the content and interpretation of xml:lang are
specified in XML 1.0 [W3C.REC-xml-20040204] Section 2.12. }}}
with:
{{{ Any element in an Atom Document MAY have an xml:lang attribute,
whose content sets the language content for the element and its
children. The language context is only significant for the language
sensitive constructs, which are indicated in this specification.
Implementations MUST preserve the language context of language
sensitive constructs. Requirements regarding the content and
interpretation of xml:lang are specified in XML 1.0
[W3C.REC-xml-20040204] Section 2.12. }}}
In section 3.1, add the sentence:
{{{ Except for the type attribute, the content of Text constructs is
language sensitive. }}}
In section 3.2.1, add the sentence:
{{{ The content of atom:name is language sensitive. }}}
In section 4.6.5, add the sentence:
{{{ The content of the title attribute is language sensitive. }}}
In section 4.13.3, add the sentence:
{{{ The content of the label attribute is language sensitive. }}}
In section 4.15, add the sentence:
{{{ Except for the type and src attributes, the content of
atom:content is language sensitive. }}}
== Impacts ==
Depending on which extension paces are accepted, a statement on the
default language sensitivity of extension elements will need to be
made.
--
Dave
Re: Call for final Paces for consideration: deadline imminent
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 that isnt present in a newer version, does that property still apply to the new instance? The answer is presumably 'no' but it isn't obvious from the spec. Under a 'multiple instances' model, it would be implicit. +1 now go write a pace, and quickly e. My plan was to take the Atom Concepts section of the document, add Entry Instance to it, and do a bit of find/replacing to make it clear that properties are properties of the instance and id is the id of the Entry itself. Unfortunately there is no Atom Concepts section, so I have not had time to do this. Currently the only definition of what an entry or feed is in the informal introduction in the first couple of sentences of the specification. I think we should to insert an Atom Concepts section before the current section 2 so that we can properly explain the important terms in Atom before we can talk about how to represent them in the format. Can we fix this as an editorial issue? There is enough confusion about entries and ids amongst the working group, nevermind the readers. -- Dave
Re: BAG Question: What is a feed? Sliding-Window or Current-State?
On 7 Feb 2005, at 00:09, Roy T. Fielding wrote: On Feb 6, 2005, at 2:24 PM, Dan Brickley wrote: * John Panzer [EMAIL PROTECTED] [2005-02-06 13:58-0800] Since an entry is identified uniquely by its atom:id (though it can have different states at different times); As I understand the Web, the REST concepts that underpin HTTP are quite happy with their being multiple representations of the selfsame resource *at the time*. Also at multiple times. Yes, it's all about time, but also about resources. The entry is a resource, and that resource may have multiple representations at a single time (atom, rss1, rss2) and also over different times. A resource has a single state at one point in time, but may have different states over time (in some case they must have different states over time because that is the essence of what makes them a resource, just as a clock is expected to have different state). URIs identify resources, not necessarily singular states. It is about resources, but the question is what the id resource identifies. There are two things the id resource could identify: a- the uri of the entry (rdf:about) b- a uri related to the entry by the id relation (rdf:resource) I find interpretation b to be the most powerful one, because it allows us to narrow the disagreement between both factions down to the properties of the id relation. Here is how I model in rdf arrow notation the atom example [1]: _entry |--title- Atom Powered Robots Run Amok |--link-- http://example.org/2003/12/13/atom03 |--id vemmi://example.org/2003/32397 |-update- 2003-12-13T18:30:02Z^^xsd:dateTime The differences this group has as to the interpretation of the id relation can be explained as follows: -those that like Bob Wyman and me-currently, believe that id is just a functional relation. Call this the [Functional Id] theory. -others like Roy Fielding and me-when-I-first-thought-of-the-issue, think of id as an equivalence relation (which I think just means that the relation is functional, symmetric and transitive). Call this the [Equivalence Id] theory. Under the [Equivalence ID] theory, the above graph has the following graph as consequence. vemmi://example.org/2003/32397 |--title- Atom Powered Robots Run Amok |--link-- http://example.org/2003/12/13/atom03 |-update- 2003-12-13T18:30:02Z^^xsd:dateTime The above conclusion cannot be drawn from the [Functional ID] theory. Note that both theories: - are expressed in terms of resources - could easily be compatible: it would just require distinguishing the [Equivalence ID] relation and the [Functional ID] relation by naming them differently. Let us do so now: [Functional ID] - funcId [Equivalence ID] - equivId Feeds are sliding window resources, but their representations do not slide -- they are fixed at a given point in time. Yes, I agree. But the time component is only as important as you say if you emphasize http URIs for your id. But that will come out more clearly below. If it is reasonable to say that, at any single point in time, only one representation of a given entry can appear in the feed's representation, then the only valid representation of a feed is one that does not contain any duplicate entry id's. This is true only if you have the [Equivalence ID] interpretation of the id relation. (Ie you think of id as equivId.) To give a more concrete example let us use the well understood http URIs for our ids, and let us disambiguate the two id types. _entry |--title--- Atom Powered Robots Run Amok |--link-- http://bblfish.net/2005/02/07/entry03/v2/entry.html |--funcId-- http://bblfish.net/2005/02/07/entry03/ |--equivId- http://bblfish.net/2005/02/07/entry03/v2/ |-update--- 2003-12-13T18:30:02Z^^xsd:dateTime The file system layout would be something like the following (taking root at 2005/02/07 to save space) entry03-- a directory resource pointed to by the funcId uri entry03/v1 -- a directory resource for the previous entry version entry03/v1/entry/xml -- the first entry version of the xml entry03/v1/entry.html -- the second entry version in html form entry03/v2 -- a directory resource pointed to by the equivId uri entry03/v2/entry.xml -- the second entry version in xml format entry03/v2/entry.html -- the first entry version in html format With the above file system layout it would therefore be completely feasible to have a feed that would correctly state at a precise time the following: feed entry titleAtom-Powered Robots Run Amok/title link href=http://bblfish.net/2005/02/07/entry03/v1/entry.html/ funcIdhttp://bblfish.net/2005/02/07/entry03//id equivIdhttp://bblfish.net/2005/02/07/entry03/v1//id updated2003-12-13T18:30:02Z/updated /entry entry titleAtom-Powered Robots Run Amok/title link href=http://bblfish.net/2005/02/07/entry03/v2/entry.html/ funcIdhttp://bblfish.net/2005/02/07/entry03//id equivIdhttp://bblfish.net/2005/02/07/entry03/v2//id
Re: BAG Question: What is a feed? Sliding-Window or Current-State?
On Feb 6, 2005, at 6:42 PM, Bob Wyman wrote: Roy T. Fielding wrote: Aggregators do not consume feed resources -- they consume an iterative set of overlapping feed representations. This is only true of pull based aggregators that poll for feeds. None of the aggregators that I use are polling based. I use the PubSub Sidebars and the Gush aggregator built by 2entwine.com. These aggregators consume streams of entries that are pushed to them using the Atom over HTTP protocol. No, they consume feed representations of length=1, which contains an entry representation. They are neither streams nor entries, and if we stop confusing the messages received with the rather abstract notion of what the author considers to be their entry, then it is much easier to understand what the id tells the recipient. This is not specific to the transfer protocol. It is an aspect of message passing architectures. Most network-based systems build tremendously complex synchronization and update mechanisms in an attempt to make message passing match what an ideal world would consider reality. Unfortunately for them, the theory of relativity is just as applicable to software as it is to us. HTTP (or at least the use of HTTP based on REST) changes the perspective by acknowledging that messages are not the same as what is identified. It seems a little odd, at first, but it makes a huge difference because clients stop assuming that they have a complete understanding, servers supply more explicit information about what they do send, and the overall system becomes less brittle during failures. However, HTTP only tries to match what is already true of message passing -- it does not make the rules. Regardless of the protocol used to receive an atom feed, the only things that will actually be received are representations. Computers can't transfer a temporal mapping that has yet to be defined. Roy
Re: PaceJoinSectionSixAndTen
-1. IETF documents have to have a Security Considerations section that describes general security issues. In no cases that I know of do they contain protocol specification. See RFC 3552 for more info. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceClarifyDateUpdated
--On February 6, 2005 1:07:42 PM +0200 Henri Sivonen [EMAIL PROTECTED] wrote: Yes. Also as a spec expectation--that is, how often is the SHOULD NOT expected to be violated. Will the SHOULD NOT be violated so often that it dilutes the meaning of all SHOULD NOTs? Roughly, a SHOULD or SHOULD NOT can be violated when the implementer understands and accepts the interoperability limitations they of that decision. So, the spec should (must?) explain what those are. wunder -- Walter Underwood Principal Architect, Verity
RE: PaceArchiveDocument posted
I agree, but I would put it another way. The charter requires support for archives, but we don't have a clear model for those. Without a model, we can't spec syntax. So, it is not possible for the current doc to fulfill the charter, and this document is not ready for last call. wunder --On February 6, 2005 2:00:20 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote: -1. The use cases for archiving have not been well defined or well discussed on this list. It is, I believe, inappropriate and unwise to try to rush through something this major at the last moment before a pending Last Call. bob wyman -- Walter Underwood Principal Architect, Verity
Re: PaceJoinSectionSixAndTen
Paul Hoffman wrote: -1. IETF documents have to have a Security Considerations section that describes general security issues. In no cases that I know of do they contain protocol specification. See RFC 3552 for more info. Is that -1 to the proposed title or -1 to having one section? cheers Bill
Re: PaceArchiveDocument posted
Walter Underwood wrote: I agree, but I would put it another way. The charter requires support for archives, but we don't have a clear model for those. Without a model, we can't spec syntax. We have feed documents. A series of feed documents makes an archive. I don't see why we need atom:archive after all. Robert Sayre
Re: BAG Question: What is a feed? Sliding-Window or Current-State?
On Sunday, February 6, 2005, at 07:42 PM, Bob Wyman wrote: The whole feed business is simply an artifact of the polling-based model of syndication. Interesting to hear the architecture for the model that most people use today be referred to as an artifact. But yeah, to someone who doesn't used polling aggregators, it would seem so. The polling oriented, feed-based model of syndication results in significant waste of network bandwidth The sliding window view into the historical states of entries (vs. a sliding window into the current states of entries) would also waste some bandwidth transmitting obsolete entry states, and could result in missed entries if someone writing an entry does a lot of tweaking and publishes each tweak (thus filling their feed document with versions of a single entry), which, though sloppy methodology, is probably not entirely uncommon--just my guess. Polling combined with diffs of the current state of entries would use similar bandwidth to push... and processing resources ...and wouldn't require the server to keep track of all of its subscribers, and would result in bandwidth usage being spread over time better than push, assuming push servers push new entries out to everyone as quickly as possible after they're published. Both methods have their advantages, many more of which could be listed on either side, I'm sure. While the use of push-based aggregators may not be widespread, it does not make sense, I think, to bind Atom to the inefficient, high-latency polling model when we know that there is a workable alternative approach -- which is far superior in at least some important applications of syndication. Agreed. But I've lost track of what aspect of Atom's architecture you are saying is bound to polling at the expense of push. Are we still talking about sliding window vs. current state? If so, what difference does that make to a push-based aggregator?
Re: PaceArchiveDocument posted
+1. We need to at least discuss the model a bit more before agreeing to a syntax. As with all things, there are many different ways we can do this -- a new top level elements, the @profile attribute Mark and I have been pitching, etc -- but unless we identify the general requirements and a general model that we're shooting for, whatever we scrap together here at the last minute is not going to be completely adequate. - James M Snell Walter Underwood wrote: I agree, but I would put it another way. The charter requires support for archives, but we don't have a clear model for those. Without a model, we can't spec syntax. So, it is not possible for the current doc to fulfill the charter, and this document is not ready for last call. wunder --On February 6, 2005 2:00:20 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote: -1. The use cases for archiving have not been well defined or well discussed on this list. It is, I believe, inappropriate and unwise to try to rush through something this major at the last moment before a pending Last Call. bob wyman -- Walter Underwood Principal Architect, Verity
Re: PaceArchiveDocument posted
On Monday, February 7, 2005, at 10:06 AM, Robert Sayre wrote: Walter Underwood wrote: I agree, but I would put it another way. The charter requires support for archives, but we don't have a clear model for those. Without a model, we can't spec syntax. We have feed documents. A series of feed documents makes an archive. I don't see why we need atom:archive after all. If Atom Documents are not allowed to contain multiple instances of a particular resource, then archiving the states of an entry would require the feed to be split into more, smaller feed documents any time an entry is edited without many other entries being published in between edits. For example, if you published an entry, decided to revise a paragraph and published again, found a misspelling and published again, and then fixed and published another misspelling, you'd need four documents, two of which would only contain one entry. Doable, yes. But a little ugly. If, on the other hand, a feed document is a sliding window into the historical states on entries (and thus, must allow multiple instances of particular entries), and if we don't want to archive the state of the feed, then we don't need a separate archive document type. The latter seems likely to be supported by the WG, but the former does not. I'd rather have an archive document type, and not repeat entries in normal feeds.
RE: PaceArchiveDocument posted
Antone Roundy wrote: entry id revision=3foo:bar/a/id ... /entry ...where @revision is a number whose only requirement is that the number for a later revision be greater than the number for an earlier revision, but skipping numbers is allowed. Providing an explicit revision number exclusively in atom:archives has both advantages and costs. If we assume that revision numbers start at 0 or 1 and increase monotonically, then revision numbers gets us: 1. The ability to name or explicitly identify different versions of an entry. 2. The ability to determine the order in which entries were written -- independent of document order. 3. The ability to detect missing entry versions. The cost of the three benefits above is, of course, the increased complexity that comes from needing to maintain the version number associated with an entry. Given that revision is an attribute which is not to be stored in a normal feed document, this means that the feed document itself cannot be used as the primary entry storage mechanism -- as is the case in some systems today. In order to maintain revision numbers, a site that provided an archive would have to have storage/memory external to the feed document. The feed document could not be considered a complete representation of even the current the state of the feed since part of the state of the feed (the revision numbers of the current entries) would be stored externally to the feed. The first two benefits of version numbers can be had without a requirement for maintaining any state if we make the version number a DateTime. The requirement for saving state external to the feed document could be removed by simply permitting the revision number to appear in the feed document. Is the third benefit -- detection of missing entries -- worth the cost of requiring that state be maintained? Is it worth it in light of the fact that a stateless alternative exists that provides all the other benefits? Is a revision attribute such a bad thing that it is really necessary to increase the complexity of the system by requiring that it be stored and maintained external to the feed document itself? Wouldn't it be easier to just allow sites that archive to include the revision number in their feed documents? Given the two arguments above, it would seem that atom:modified (must be updated on the change of any byte in an entry) would provide all of the benefits that appear to be desired with the exception of missing entry detection. Of course, if we went a step further and said that the unique identifier for an entry was the concatenation of atom:id + (atom:revision OR atom:modified), then we would no longer require the archive document type at all... But, I won't go there... bob wyman
Re: PaceArchiveDocument posted
Hmm... ok, at this point we have a point of disagreement. I see archiving individual entries as being more important (or at least equally important) as archiving feeds. Example: my weblog is a collection of entries, not a collection of feeds. The feed published by my weblog is just a snapshot of a given point in time designed to allow others to read my entries without visiting my site. When I archive, what I want to archive are the entries, not the feed. archivefeed /feed //archive does not make any sense to me. archiveentry /entry //archive does. (ignore the angle brackets for now, I'm not trying to promote the idea of the archive element, I'm just illustrating my point). Now, if I had my way, I would *probably* spec this out as: * Archives work fundamentally on the entry level. * An archived entry consists of all versions of the entry. * Feeds are only archived as they relate to archived entries. For example, if a given entry has an associated comments feed, or some form of nested discussion feed, etc. Such feeds are logically considered part of the metadata of the entry. - James M Snell Robert Sayre wrote: Walter Underwood wrote: I agree, but I would put it another way. The charter requires support for archives, but we don't have a clear model for those. Without a model, we can't spec syntax. We have feed documents. A series of feed documents makes an archive. I don't see why we need atom:archive after all. Robert Sayre
Re: PaceArchiveDocument posted
James M Snell wrote: +1. We need to at least discuss the model a bit more before agreeing to a syntax. As with all things, there are many different ways we can do this -- a new top level elements, the @profile attribute Mark and I have been pitching, etc -- but unless we identify the general requirements and a general model that we're shooting for, whatever we scrap together here at the last minute is not going to be completely adequate. The word archive shouldn't have been in the charter. Since no one even bothered to define the term over the past 8 months, I will do it now. Archiving -- It must be possible to serialize a complete collection of entries using the Atom Format. Robert Sayre
Re: AtomPubIssuesList for 2005/02/07
Thanks, Sam. Everyone: as Tim and I said last week, this is the last set of Paces we are considering for inclusion in the format document. If it's not on this list, it isn't considered unless you can show that there is a dire technical or security flaw in the document. Please comment on each Pace separately. Even if you sent in a +1, 0, or -1 previously on a particular Pace, send it in again. Hopefully, add a short or long comment on why you feel it should or should not be considered part of the Atom core. Aggregated lists are cute, but greatly hurt the ability to hold a conversation. Some of the Paces in this last round cover interesting and useful topics. Note, however, that interesting and useful does not mean core to Atom. We don't/can't have a strict definition of what is core to the protocol, but after over a year, many of us have a good feeling for that. And, let's remember to have useful Subject: lines, OK? If a thread changes direction, please change the subject line. Thanks! --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceArchiveDocument posted
Collecting a bunch of recent discussion into one document, how about these for a set of terms and their meanings: * Entry: An abstract term describing a unit of content and metadata associated with it. * Entry Representation: A representation of a particular state of a particular entry. * Entry Document: A document, whose document element is entry, which contains a single Entry Representation. * Feed: An abstract term describing a stream of Entry Representations. * Feed Document: No such thing--replaced by Collection Documents and Archive Documents. * Collection: Entry Representations of the current states of the Entries from a Feed. * Collection Document: A document, whose document element is collection, which contains a Collection or a portion of a Collection. * Archive: Entry Representations of the historical states of the Entries from a Feed. * Archive Document: A document, whose document element is archive, which contains an Archive or a portion of an Archive. Archive documents may contain multiple Entry Representations of the same Entry. Publishers may choose to publish only Collection Documents, only Archive Documents, only Entry Documents, or any combination of these. So, for example, a publisher who does not track the historical states of their Entries might publish only a Collection Document. A publisher who DOES track the historical states of their Entries might publish only an Archive Document, or both Collection and Archive Documents, or only a Collection Document. Processing an Archive Document would be slightly more complicated than processing a Collection Document for clients that don't track the history of a Feed--for example, scripts that simply display the current contents of a Document on a website, because they might need to choose one from among multiple Entry Representations of the same Entry for display or other processing. On Monday, February 7, 2005, at 10:13 AM, James M Snell wrote: +1. We need to at least discuss the model a bit more before agreeing to a syntax. As with all things, there are many different ways we can do this -- a new top level elements, the @profile attribute Mark and I have been pitching, etc -- but unless we identify the general requirements and a general model that we're shooting for, whatever we scrap together here at the last minute is not going to be completely adequate. - James M Snell Walter Underwood wrote: I agree, but I would put it another way. The charter requires support for archives, but we don't have a clear model for those. Without a model, we can't spec syntax. So, it is not possible for the current doc to fulfill the charter, and this document is not ready for last call. wunder --On February 6, 2005 2:00:20 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote: -1. The use cases for archiving have not been well defined or well discussed on this list. It is, I believe, inappropriate and unwise to try to rush through something this major at the last moment before a pending Last Call. bob wyman -- Walter Underwood Principal Architect, Verity
PaceArchiveDocument
-1. Not core. The current text has a simple way of creating archives, and extensions can be used to create more specialized archive formats. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceJoinSectionSixAndTen
At 5:09 PM + 2/7/05, Bill de hÓra wrote: Paul Hoffman wrote: -1. IETF documents have to have a Security Considerations section that describes general security issues. In no cases that I know of do they contain protocol specification. See RFC 3552 for more info. Is that -1 to the proposed title or -1 to having one section? The latter. In IETF documents, there should be a section that tells you how to do security, and another section that shows the bigger picture about security (such as known threats, other interesting security work, and so on). --Paul Hoffman, Director --Internet Mail Consortium
PaceEntryOrder
+1. It is a simple clarification that shows the intention without restricting anyone. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceArchiveDocument posted
Yuck. I don't like the granularity of that at all. I can see checking in individual entries, but not a single feed with every entry. What if I'm just changing the value of a single title attribute? Should I have to regenerate the entire feed and check in the entire feed just to update the archive for one minor edit? That would be kind of like taking all the source code for a given project, zipping it up into a single zip file and checking that into subversion. Sure, it would work, but dang that's nasty (not that it's not being done). Better to archive individual entries. Sure, archiving of feeds can be done also, but archiving feeds is separate from archiving entries. They are separate documents, treat them separately. - James M Snell Robert Sayre wrote: Antone Roundy wrote: If Atom Documents are not allowed to contain multiple instances of a particular resource, then archiving the states of an entry would require the feed to be split into more, smaller feed documents any time an entry is edited without many other entries being published in between edits. For example, if you published an entry, decided to revise a paragraph and published again, found a misspelling and published again, and then fixed and published another misspelling, you'd need four documents, two of which would only contain one entry. Doable, yes. But a little ugly. No, I'm saying I would regenerate a feed with every entry in it every time I make a change. Then, I would check it into Subversion. Robert Sayre
Removing your old Paces from consideration
Someone pointed out that some of the Paces in the current rotation have been informally withdrawn by their authors. Good point. If you have such a Pace, please send mail to the list saying so, and Sam can remove it from the wiki. --Paul Hoffman, Director --Internet Mail Consortium
PaceClarifyDateUpdated
-1. Doesn't make sense or add value to the document. Robert Sayre
Re: PaceEntryOrder
Paul Hoffman wrote: +1. It is a simple clarification that shows the intention without restricting anyone. +1. Agree in full. Robert Sayre
Re: PaceArchiveDocument
Paul Hoffman wrote: -1. Not core. The current text has a simple way of creating archives, and extensions can be used to create more specialized archive formats. -1 to the Pace. Agree in full. Robert Sayre
Re: PaceJoinSectionSixAndTen
Paul Hoffman wrote: The latter. In IETF documents, there should be a section that tells you how to do security, and another section that shows the bigger picture about security (such as known threats, other interesting security work, and so on). I can tell this isn't worth arguing about :) I've withdrawn the pace and notified Sam. cheers Bill
Re: AtomPubIssuesList for 2005/02/07
Sam Ruby wrote: Like I did last time, I am simply scheduling all the open format items in the hopes that we can drive this list to zero. PaceJoinSectionSixAndTen Hi Sam, I'd like to withdraw this one from consideration, it doesn't fit with the IETF way (...mumbles darkly about the ietf way...). cheers Bill
PaceDatesXSD
+1. Our AD has told us how to write this section, so the Pace just adds the regex, which I'm in favor of. Sam's suggestion at the end could easily be accomodated with a sentence saying As a result, the date values are valid according to [RFC3339], [XML-SCHEMA], and [w3cdtf]. Robert Sayre
Re: PaceArchiveDocument posted
On Monday, February 7, 2005, at 10:26 AM, Bob Wyman wrote: Antone Roundy wrote: entry id revision=3foo:bar/a/id ... /entry ...where @revision is a number whose only requirement is that the number for a later revision be greater than the number for an earlier revision, but skipping numbers is allowed. Providing an explicit revision number exclusively in atom:archives has both advantages and costs. If we assume that revision numbers start at 0 or 1 and increase monotonically, then revision numbers gets us: 1. The ability to name or explicitly identify different versions of an entry. 2. The ability to determine the order in which entries were written -- independent of document order. 3. The ability to detect missing entry versions. The cost of the three benefits above is, of course, the increased complexity that comes from needing to maintain the version number associated with an entry. Only if the version number for a particular Entry Representation needs to remain constant. I'd be fine with it either way--simplicity and only #2 (and limited #1--you can do it within the context of a particular instance of the archive, but can't be sure it won't change when you download the archive again) vs. storing the version number and getting all 3. The first two benefits of version numbers can be had without a requirement for maintaining any state if we make the version number a DateTime. Of course, you'd have to store the DateTime. It's more likely that people are already doing that, so for those that are, this would be preferable. Those who aren't are likely not storing the historical states of the entry at all. Is a revision attribute such a bad thing that it is really necessary to increase the complexity of the system by requiring that it be stored and maintained external to the feed document itself? Wouldn't it be easier to just allow sites that archive to include the revision number in their feed documents? I'd have no problem with allowing that. Given the two arguments above, it would seem that atom:modified (must be updated on the change of any byte in an entry) would provide all of the benefits that appear to be desired with the exception of missing entry detection. True. Rather than going back into the whole discussion of dates, we could let people who want to get benefits #1 and #2 can store dc:modified (since atom:modified) doesn't currently exist, and those who don't do that can either invent their own extension like @revision. So archive documents as defined in Atom wouldn't include either, and the market would show us which would prevail. I'm feeling a little apathetic about exactly how we do it at the moment.
PaceSecuritySection
+1. Says all that we need to without getting into HTML too deeply. Robert Sayre
Re: PaceCaching posted
This is not restricted to HTTP. It uses HTTP's cache age algorithms, because they are very carefully designed and have proven effective. But it can be used for any local copy in an Atom client. wunder --On Monday, February 07, 2005 10:08:48 AM -0800 Paul Hoffman [EMAIL PROTECTED] wrote: At 9:38 AM -0800 2/7/05, Walter Underwood wrote: I was holding this back as out of scope and too close to the deadline, but now that we are talking about sliding windows and delayed, cached state, it is quite relevant. Sorry, this is too late for consideration for the Atom core. Even if you had turned it in on time, I would give it a -1 for not being essential to the core for the Atom format. Atom will be distributed over many protocols, HTTP being one of them. Having said that, I think this would be an excellent extension, one that might keep the folks who don't understand HTTP scalability but feel free to talk about it anyway at bay. --Paul Hoffman, Director --Internet Mail Consortium -- Walter Underwood Principal Architect Verity Ultraseek
PaceMultipleImages
Some feel that since the atom:image could contain text, multiple instances ought to be allowed for to support multilanguage. These people are wrong. -1 to the Pace. Robert Sayre
Re: PaceArchiveDocument
-1 to the Pace. The current syntax sufficiently meets the 'support for archives' charter, and extensions are possible. -John
PaceNoFeedState
+1. There are too many little details that we haven't worked out in exactly how to reconstruct the state of a feed to try to define it now.
RE: BAG Question: What is a feed? Sliding-Window or Current-State?
Antone Roundy wrote: [polling] would result in bandwidth usage being spread over time better than push, assuming push servers push new entries out to everyone as quickly as possible after they're published. At PubSub, we operate both a push and a pull service. We know from experience that the push service results in drastically less bandwidth per user then the polling service does. This is not based on theory -- rather the statement is based on real empirical evidence of running both services side by side. The bandwidth savings of the push service comes from the fact that we don't have to handle the poll requests themselves and we never publish the same item twice to a single subscriber as is inevitably the case with a multi-entry polled RSS/Atom file. In order to demonstrate polling at its most efficient, I defined and convinced a number of folk to implement RFC3229+feed. This HTTP extension eliminates the problem with sending multiple copies of messages to people and the resulting drop in bandwidth requirements for those who poll and use RFC3229+feed was dramatic[1] -- however, the RFC3229+feed service still consumes more bandwidth then the push service. Once again, this ain't theory, it is experience. I've lost track of what aspect of Atom's architecture you are saying is bound to polling at the expense of push. There are several Feed-oriented or polling oriented discussions going on: 1. The requirement that feeds not be permitted to contain multiple entries that have the same atom:id. This requirement prevents push based system from using feeds as logs or histories of messages sent. For instance, at PubSub, the Atom file which is associated with every subscription contains a stream of entries that are the entries that either were or would have been sent to the client if it had been connected. The first thing a client does on starting up is to read the Atom file in order to synchronize state with the server. Thus, the feed is actually just a trace of the messages sent. This probably sounds weird if you're feed-focused; however, it makes perfect sense if you are pushing entries. 2. Significance of the order of entries in feeds. A push-fed client only sees feeds in edge cases (like the PubSub synchronization usage discussed above). Because a push-fed client receives a stream of entries -- not feeds, it can only see chronological order unless order is encoded within the entry itself. Any requirement that document order is significant (and some are still suggesting it is) means that a push-based system must push entire feeds rather then individual entries. The bandwidth costs of doing so would be completely unacceptable. (Things like ordered lists should be handled by having entries that contain ordered lists. Exploiting the anecdotal attributes of the atom:feed document and the practices of current aggregators is NOT reasonable.) 3. The absence of a revision id or atom:modified. The feed-ists don't see the need for revision numbers in part because they are focused on feeds rather than entries. If you live in the world of entries -- as a push system does -- then the need to distinguish multiple versions of the same entry becomes much, much more important. I have an additional set of concerns that are based on our experience as generators of aggregate feeds. The problem is that we are at the mercy of the creators of feeds... The rules say, as they should, that we're not supposed to change the atom:id of something that we extract from a feed. Thus, when we generate results, we should use the atom:id's that we found in the source entries. However, if someone fails to create really unique atom:id's, we are left wondering what to do... We aren't supposed to generate a feed with repeat atom:id's according to the spec, however, our users will want to see all entries that match their search terms. We have to either conform to the Atom spec by dropping one of the Entries from the results -- and thus serve our users less well, or, we have to generate new atom:id's in order to serve our users but violate the specification. In other words, we can't win. Similarly, the prohibition against multiple instances of an atom:id means that we can't implement a show me all versions feature using Atom as the packaging format for the results. (No, we're not planning to do this. But, it would be good to be able to do it.) bob wyman [1] http://bobwyman.pubsub.com/main/2004/10/massive_bandwid.html
Re: PaceEntryOrder
--On February 7, 2005 1:06:49 PM -0500 Robert Sayre [EMAIL PROTECTED] wrote: Paul Hoffman wrote: +1. It is a simple clarification that shows the intention without restricting anyone. +1. Agree in full. -1. I don't see the benefit. Clients MAY re-order them, but that doesn't mean they MUST ignore the order. The publisher may prefer an order which cannot be expressed in the attributes. The Macintouch and BBC New feeds cited before are good examples. wunder -- Walter Underwood Principal Architect, Verity
PaceIconAndImage
+1 if image is changed to logo or, even better, if image is allowed in entry. I don't care whether icon is allowed in entry, though I see no reason not to allow it.
PaceLinkEnclosure
+1, and +1 to calling it attachment instead of enclosure.
PaceFormatSecurity
+1. But let's add something to the effect of consumers MAY ignore unrecognized CSS/(X)HTML and any CSS/(X)HTML that they are not confident will not result in security problems.
PaceSecuritySection
-1: Not enough information. We may not need all the detail of PaceFormatSecurity, but PaceSecuritySection goes too far the other way.
Re: PaceSecuritySection
At 1:17 PM -0500 2/7/05, Robert Sayre wrote: +1. Says all that we need to without getting into HTML too deeply. Wearing my IETF hat, +1. Also, be aware that there is probably a 50% chance that we will get additions to this section from the IETF last call or from the IESG. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceFormatSecurity
-1. If the current security documents that cover the material are insufficient, they should be fixed, and not have it listed in our document. We should only point to where generic information can be found and list things that are Atom-specific. --Paul Hoffman, Director --Internet Mail Consortium
PaceXhtmlNamespaceDiv
On Feb 7, 2005, at 19:50, Paul Hoffman wrote: Even if you sent in a +1, 0, or -1 previously on a particular Pace, send it in again. Hopefully, add a short or long comment on why you feel it should or should not be considered part of the Atom core. -1 on PaceXhtmlNamespaceDiv The div is an additional container inside the Text construct container. The main purpose of the div is to save one for loop in a document-tree/pull-based client or, alternatively, to give a false sense of correctness in tag soup concatenation-based clients. IMO, neither rationale warrants a meaningless element inside a Text construct. (Noting that the Pace was retracted by the original author.) -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceEntryOrder
Walter Underwood wrote: --On February 7, 2005 1:06:49 PM -0500 Robert Sayre [EMAIL PROTECTED] wrote: Paul Hoffman wrote: +1. It is a simple clarification that shows the intention without restricting anyone. +1. Agree in full. -1. I don't see the benefit. Clients MAY re-order them, but that doesn't mean they MUST ignore the order. The publisher may prefer an order which cannot be expressed in the attributes. The Macintouch and BBC New feeds cited before are good examples. I'm +1 on the Pace as written. I'd be equally +1 on a modifed Pace where SHOULD NOT was used in place of MUST NOT. - Sam Ruby
Re: PaceXhtmlNamespaceDiv
Henri Sivonen wrote: On Feb 7, 2005, at 19:50, Paul Hoffman wrote: Even if you sent in a +1, 0, or -1 previously on a particular Pace, send it in again. Hopefully, add a short or long comment on why you feel it should or should not be considered part of the Atom core. -1 on PaceXhtmlNamespaceDiv The div is an additional container inside the Text construct container. The main purpose of the div is to save one for loop in a document-tree/pull-based client or, alternatively, to give a false sense of correctness in tag soup concatenation-based clients. IMO, neither rationale warrants a meaningless element inside a Text construct. (Noting that the Pace was retracted by the original author.) It was retracted due to a perceived lack of interest - at that point it was a two party dialog between yourself and that author. Since then a number of folks (myself included) expressed support for this Pace, I reopened it with an email to the list, and I will now reiterate my support now with a +1. There are a number of issues that this resolves, such as whether the div element itself is to be considered part of the content in protocol POST methods. If they are not, you will tend over time to see multiple such wrappings. -Sam Ruby
Re: BAG Question: What is a feed? Sliding-Window or Current-State?
On Monday, February 7, 2005, at 12:00 PM, Bob Wyman wrote: In order to demonstrate polling at its most efficient, I defined and convinced a number of folk to implement RFC3229+feed. This HTTP extension eliminates the problem with sending multiple copies of messages to people and the resulting drop in bandwidth requirements for those who poll and use RFC3229+feed was dramatic[1] -- however, the RFC3229+feed service still consumes more bandwidth then the push service. Once again, this ain't theory, it is experience. You are of course the one in a position to know about this. I'm curious though--do you have figures on how much push reduced bandwidth use vs. RFC3229+feed? My guess would be that the difference wouldn't be as dramatic as between feed and RFC3229+feed, but I recognize that I may be wrong. That guess is what I was expressing. I've lost track of what aspect of Atom's architecture you are saying is bound to polling at the expense of push. There are several Feed-oriented or polling oriented discussions going on: 1. The requirement that feeds not be permitted to contain multiple entries that have the same atom:id. This requirement prevents push based system from using feeds as logs or histories of messages sent. For instance, at PubSub, the Atom file which is associated with every subscription contains a stream of entries that are the entries that either were or would have been sent to the client if it had been connected. The first thing a client does on starting up is to read the Atom file in order to synchronize state with the server. Thus, the feed is actually just a trace of the messages sent. This probably sounds weird if you're feed-focused; however, it makes perfect sense if you are pushing entries. It doesn't sound particularly weird, though I don't understand why the typical client would feel the need to see obsolete representations of entries that had been changed more than once while they were offline. I fully agree that we should not lock out the option of including multiple instances of an entry in some kind of Atom Document. But I also don't think that we should require all Atom Documents (other than Entry Documents) to do so. In other words, I don't think this is an either-or question--I think both should be possible. 2. Significance of the order of entries in feeds. A push-fed client only sees feeds in edge cases (like the PubSub synchronization usage discussed above). Because a push-fed client receives a stream of entries -- not feeds, it can only see chronological order unless order is encoded within the entry itself. Any requirement that document order is significant (and some are still suggesting it is) means that a push-based system must push entire feeds rather then individual entries. The bandwidth costs of doing so would be completely unacceptable. Agreed. 3. The absence of a revision id or atom:modified. The feed-ists don't see the need for revision numbers in part because they are focused on feeds rather than entries. If you live in the world of entries -- as a push system does -- then the need to distinguish multiple versions of the same entry becomes much, much more important. Makes sense. I personally have come to like the idea of using dc:modified rather than defining atom:modified. (I am a proponent of atom:updated because there is no Dublin Core equivalent for it).
Re: PaceIconAndImage
-1. image should be exactly as it is in RSS, except with the recommendation that it should be 1:1, instead of size recomendations. There's also no reason to limit it to atom:head. icon is silly. link rel=icon should usher in the brave new world of HTML relations leaking into the Atom space. Alright. Robert Sayre
Re: PaceEntryOrder
+1. Low cost, good benefits for interoperability.
PaceXhtmlNamespaceDiv
+1, but I wouldn't object to a variant that required either the DIV with a namespace declaration OR for the namespace to be declared in content or before content. Examples of what I'd think was acceptable: feed ... xmlns:xhtml=... / ... contentThis is xhtml:bbold/xhtml:b/content OR content xmlns:xhtml=... /This is xhtml:bbold/xhtml:b/content OR contentdiv xmlns=... /This is bbold/b/content Here's what I think is just plain ugly and shouldn't be allowed: contentThis is b xmlns=... bold/b/content OR contentThis is xhtml:b xmlns:xhtml=... bold/xhtml:b/content
Re: PaceEntryOrder
+1, with the proviso that I think the first sentence is entirely meaningless. Graham
Re: PaceFormatSecurity
Sam Ruby wrote: It seems to me that we have an obligation to either (1) disallow HTML, or (2) mitigate allowing HTML by providing a security section such as this one. If (2) can be solved by reference, then that clearly would be preferred. But to date, no such reference has been found. So, engaging in bad specification practice[0] is the answer? HTML security is a problem for the W3C and/or an HTML-WG. Existing RFCs constitute the IETF's definition of adequate security coverage for HTML. If we want to change the status quo in our document, we need to say that we're updating those RFCs at the top of our document. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg12625.html
Re: PaceFormatSecurity
-1, agree with Robert. Graham On 7 Feb 2005, at 6:35 pm, Robert Sayre wrote: -1. Covers HTML in too much detail, though it's still inadequate coverage. This is isn't our problem. I blame the W3C :) Robert Sayre
Re: PaceXhtmlNamespaceDiv
On 7 Feb 2005, at 7:38 pm, Sam Ruby wrote: Since then a number of folks (myself included) expressed support for this Pace, I reopened it with an email to the list, and I will now reiterate my support now with a +1. There are a number of issues that this resolves, such as whether the div element itself is to be considered part of the content in protocol POST methods. If they are not, you will tend over time to see multiple such wrappings. +1, and not just because it will make my life easier. Graham
PaceCommentFeeds
+1: if not the whole Pace, then at least link/@rel=comments.
Re: PaceXhtmlNamespaceDiv
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 anyway. -- Anne van Kesteren http://annevankesteren.nl/
PaceEntriesElement
-1: recursion is too complex and bulky.
PaceFeedRecursive
-1: recursion is too complex and bulky. But we could (should?) specify lack of recursion in terms of particular types of Atom Documents or particular profiles, leaving the door open for extensions to define document types that allow recursion.
Re: PaceArchiveDocument posted
I think that the complexity that this proposal is proof of its failure. If you look at a Feed document as simply a sliding window view into the historical state of entries instead a sliding window view into the current state of entries (though as I have shown these can overlap),` then you have your archive document already. HELLO GUYS/GALS YOU ARE THERE AT THE FINISH LINE. IT ALL WORKS! One of the arguments against the sliding window view in the historical state of entries is that it was too complicated. But clearly not going that way is making things WAY MORE COMPLICATED. So before proceeding any further it may be worth now comparing the complexity of both proposals in detail. My guess is that the historical one is just a little surprising, but that is all. Henry Story
Re: PaceXhtmlNamespaceDiv
On Feb 7, 2005, at 21:52, Antone Roundy wrote: +1, but I wouldn't object to a variant that required either the DIV with a namespace declaration OR for the namespace to be declared in content or before content. Examples of what I'd think was acceptable: feed ... xmlns:xhtml=... / ... contentThis is xhtml:bbold/xhtml:b/content This is against the Pace. Are you really supporting the pace? OR content xmlns:xhtml=... /This is xhtml:bbold/xhtml:b/content This is against the Pace, too. OR contentdiv xmlns=... /This is bbold/b/content This one is against the pace as well. Also, the 'b' element would be in the same namespace as 'content', which seems wrong. Here's what I think is just plain ugly and shouldn't be allowed: contentThis is b xmlns=... bold/b/content IMO, that should be allowed. Atom has no business in restricting the syntactic sugar provided by Namespaces in XML. OR contentThis is xhtml:b xmlns:xhtml=... bold/xhtml:b/content IMO, this on should be allowed on the same grounds. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
PaceRemoveVersionAttr
+1. I'd like to see language specifying how the namespace can be used to determine compatibility between revisions of the specification--ie. any app that can handle one version of Atom can handle any version sharing the same namespace, and any feed that's valid under any version of Atom is valid under any version sharing the same namespace.
Re: PaceIconAndImage
+1, agree with renaming image to logo. Disagree with allowing either in entry, since their are already one million ways to do that (HTML, [EMAIL PROTECTED], etc). Graham On 7 Feb 2005, at 7:08 pm, Antone Roundy wrote: +1 if image is changed to logo or, even better, if image is allowed in entry. I don't care whether icon is allowed in entry, though I see no reason not to allow it.
Re: PaceArchiveDocument posted
On 7 Feb 2005, at 18:29, Antone Roundy wrote: The latter seems likely to be supported by the WG, but the former does not. I'd rather have an archive document type, and not repeat entries in normal feeds. I don't think the historical sliding window view forces you at all to duplicate the entries in your feed. The spec allows you to remove all the old versions if you wish. After all the Present time, is just one element in the sequence of history. People who only want to live in the present don't negate history. They just don't remember it. Henry Story
Re: PaceXhtmlNamespaceDiv
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 ancestor element will do. - James M Snell Antone Roundy wrote: +1, but I wouldn't object to a variant that required either the DIV with a namespace declaration OR for the namespace to be declared in content or before content. Examples of what I'd think was acceptable: feed ... xmlns:xhtml=... / ... contentThis is xhtml:bbold/xhtml:b/content OR content xmlns:xhtml=... /This is xhtml:bbold/xhtml:b/content OR contentdiv xmlns=... /This is bbold/b/content Here's what I think is just plain ugly and shouldn't be allowed: contentThis is b xmlns=... bold/b/content OR contentThis is xhtml:b xmlns:xhtml=... bold/xhtml:b/content
Re: PaceFeedRecursive
On 19 Jan 2005, at 10:38, Henry Story wrote: I think the easiest way to get what you want is a 2 step procedure: 1. Merge the Head with the Entry constructs. They are not different enough for the difference to be important. 2. Make a Feed a subclass of Entry, with the extra property of being able to point to a Entry (Since a Feed is a Entry, it also points to other Feeds) I am +1 on such a refactoring. Nothing will be lost doing this, and a lot gained in simplicity. Henry I now no longer believe 2. Is needed. 1 would be quite neat though. Henry
Re: PaceEntryOrder
At 11:07 AM -0800 2/7/05, Walter Underwood wrote: -1. I don't see the benefit. Clients MAY re-order them, but that doesn't mean they MUST ignore the order. The publisher may prefer an order which cannot be expressed in the attributes. The Macintouch and BBC New feeds cited before are good examples. I'm very confused. Clients that show the entries of those feeds in the received order are perfectly acceptable according to the wording of this Pace. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceArchiveDocument
On Feb 7, 2005, at 20:04, Robert Sayre wrote: Paul Hoffman wrote: -1. Not core. The current text has a simple way of creating archives, and extensions can be used to create more specialized archive formats. -1 to the Pace. Agree in full. -1 to the Pace. Me three. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
James M Snell 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 ancestor element will do. I'm still -1. But I was wondering, why only ancestor elements? Wouldn't the most logical thing for string based generators be to apply it on the DIV element? -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceEntriesElement
-1 I agree. Recursion can be placed in the model. It does not need to be in the syntax. In any case this is too big a change too late in the game. Henry On 7 Feb 2005, at 21:08, Antone Roundy wrote: -1: recursion is too complex and bulky.
Re: PaceXhtmlNamespaceDiv
Yes, sorry I wasn't clear. Not *only* on ancestor elements. any of the following cases should be allowed. feed entry content xhtml:div xmlns:xhtml=... / /content /entry /feed feed entry content xmlns:xhtml=... xhtml:div / /content /entry /feed feed entry xmlns:xhtml=... content xhtml:div / /content /entry /feed feed xmlns:xhtml=... entry content xhtml:div / /content /entry /feed - James M Snell Anne van Kesteren wrote: James M Snell 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 ancestor element will do. I'm still -1. But I was wondering, why only ancestor elements? Wouldn't the most logical thing for string based generators be to apply it on the DIV element?
Re: PaceXhtmlNamespaceDiv
Nah, I don't buy it. XHTML is just a special case of an XML content and if we were embedding some XML data (say an atom:feed) it wouldn't make any sense (under the assumption that the content / element is top level container) for us to do: content type=application/atom+xml head ... /head entry ... /entry /content In my opinion, the XML contained in the content or text element should be capable of standing alone outside of the content element as a well-formed document and XHTML is just a special case of XML content. - James M Snell Henri Sivonen wrote: On Feb 7, 2005, at 22:18, James M Snell wrote: There does need to be a container for the XHTML and div is a solid, logical choice. The container is the Atom Text construct itself!
Re: PaceXhtmlNamespaceDiv
For the record, the additional loop that the div would save in a
DOM-based client is not that hard:
copyLangAndBase(atomTextCostruct, targetDivInTemplate);
for (Node n = atomTextCostruct.getFirstChild(); n != null; n =
n.getNextSibling()) {
targetDivInTemplate.appendChild(templateXhtmlDocument.importNode(n,
true));
}
Is that too much to ask from clients?
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
James M Snell wrote: Nah, I don't buy it. XHTML is just a special case of an XML content and if we were embedding some XML data (say an atom:feed) it wouldn't make any sense (under the assumption that the content / element is top level container) for us to do: content type=application/atom+xml head ... /head entry ... /entry /content I do not follow this example. In my opinion, the XML contained in the content or text element should be capable of standing alone outside of the content element as a well-formed document and XHTML is just a special case of XML content. So you want a DIV as wrapper element for TITLE and similar elements as well? -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
Anne van Kesteren wrote: James M Snell 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 ancestor element will do. I'm still -1. But I was wondering, why only ancestor elements? Wouldn't the most logical thing for string based generators be to apply it on the DIV element? I'm confused. If you are opposed to this pace, then what div element? It may also be helpful to look at a specific feed, for example this one: http://www.imc.org/atom-syntax/mail-archive/msg12902.html Experiment with alternate serializations if you like. The important question is whether the div element is part of the format or part of the content? Should aggregators copy it? When an Atom entry is POSTed to a blog, is the div part of the content? - Sam Ruby
Re: PaceXhtmlNamespaceDiv
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 ancestor element will do. I'm still -1. But I was wondering, why only ancestor elements? Wouldn't the most logical thing for string based generators be to apply it on the DIV element? I'm confused. If you are opposed to this pace, then what div element? That was a question in reply to what James wrote. It appeared to be an error. It may also be helpful to look at a specific feed, for example this one: http://www.imc.org/atom-syntax/mail-archive/msg12902.html Experiment with alternate serializations if you like. The important question is whether the div element is part of the format or part of the content? Should aggregators copy it? When an Atom entry is POSTed to a blog, is the div part of the content? If the page is adopted, which I hope not, it MUST NOT be part of the content. If the page is not adopted it MUST be part of the content. -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
Anne van Kesteren wrote: James M Snell wrote: Nah, I don't buy it. XHTML is just a special case of an XML content and if we were embedding some XML data (say an atom:feed) it wouldn't make any sense (under the assumption that the content / element is top level container) for us to do: content type=application/atom+xml head ... /head entry ... /entry /content I do not follow this example. The point is that content / should not be viewed as the root element for contained XML. The XML content should be able to stand on it's own, indepedently of the content or text construct element as well-formed XML. In my opinion, the XML contained in the content or text element should be capable of standing alone outside of the content element as a well-formed document and XHTML is just a special case of XML content. So you want a DIV as wrapper element for TITLE and similar elements as well? For Text construct and Content, if XHTML is used, there should be a DIV. If someone wants to use XHTML for title, then yes, they should use a DIV. Otherwise, they can use plain text. - James M Snell
PaceProfileAttribute
-1: One profile (or maybe set of profiles) per document is better in my opinion. If an aggregator aggregates entries with different profiles, it can either fix them up as needed to conform to a common profile, or if multiple profiles can be specified at the top level, declare the profiles for all of the entries in the document there.
Re: PaceXhtmlNamespaceDiv
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 ancestor element will do. I'm still -1. But I was wondering, why only ancestor elements? Wouldn't the most logical thing for string based generators be to apply it on the DIV element? I'm confused. If you are opposed to this pace, then what div element? That was a question in reply to what James wrote. It appeared to be an error. It may also be helpful to look at a specific feed, for example this one: http://www.imc.org/atom-syntax/mail-archive/msg12902.html Experiment with alternate serializations if you like. The important question is whether the div element is part of the format or part of the content? Should aggregators copy it? When an Atom entry is POSTed to a blog, is the div part of the content? If the page is adopted, which I hope not, it MUST NOT be part of the content. If the page is not adopted it MUST be part of the content. I can easily sit back and adopt a wait and see and I told you so attitude, but by now it should be obvious that I care too much about the success of this format and protocol to do that. 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 you to experiment with alternate serializations. 3) More feeds will be invalid (content in atom namespace) 4) More feeds will be incorrect (in the sense that Tim's feed does accurately reflect the content of his entries). 5) For some combinations of clients and servers, entries produced via an HTTP POST will end up with multiple divs. Meanwhile, now that the location where the namespace can be declared details have been removed from this pace, Henri can continue to do a DOM-to-DOM copy. I stand by my original statements: There are cases where explicit is better than implicit. Given that common practice is to include this element, making it mandatory makes things clearer to both people who are producing consuming tools based on the spec, and people who are producing new feeds based on copy and paste. - Sam Ruby
Re: PaceEntryOrder
David Powell wrote: Monday, February 7, 2005, 7:23:15 PM, you wrote: I'm +1 on the Pace as written. I'd be equally +1 on a modifed Pace where SHOULD NOT was used in place of MUST NOT. Sam, have you misread the Pace? The only occurrence of MUST NOT is in the Rationale, where it has been copied from Atom 0.3 as an example. The proposal is to add the following paragraph: This specification assigns no significance to the order of atom:entry elements within the feed. Processors MAY present entries in a different order to which they are appear in an Atom Feed Document. Also, Walter's comment seems to suggest the same confusion: -1. I don't see the benefit. Clients MAY re-order them, but that doesn't mean they MUST ignore the order. The publisher may prefer an order which cannot be expressed in the attributes. The Macintouch and BBC New feeds cited before are good examples. I'll try to be a bit more conservative with the PRE tags in future :) Yes, I misread it. To be clear: 1) I am +1 to the original wording that somehow got lost. 2) I am +1 to the proposed rewording. Ultimately, the sentiment that I want conveyed is that publishers are not safe to assume that clients will read anything into the order. - Sam Ruby
PaceAggregationInSeparateSpec
+1 if: 1) it means that head-in-entry is removed. AND 2) profiles or some extension mechanism would enable people to do head-in-entry for those who want to use that method, but which I DON'T mean this: entry ext:head ext:feed-title / ext:feed-updated / ... /ext:head ... /entry but this: entry ext:head title / updated / ... /ext:head ... /entry
Re: PaceEntryOrder
--On Monday, February 07, 2005 12:24:15 PM -0800 Paul Hoffman [EMAIL PROTECTED] wrote: At 11:07 AM -0800 2/7/05, Walter Underwood wrote: -1. I don't see the benefit. Clients MAY re-order them, but that doesn't mean they MUST ignore the order. The publisher may prefer an order which cannot be expressed in the attributes. The Macintouch and BBC New feeds cited before are good examples. I'm very confused. Clients that show the entries of those feeds in the received order are perfectly acceptable according to the wording of this Pace. Correct, clients may choose any order, including the original. This is about the publisher's order preference. The Pace says that the publisher cannot indicate a preferred order in the Atom format. The order is not significant. This is clearly counter to normal use, where the order does have some meaning. The meaning varies by publisher, but it is usually significant. wunder -- Walter Underwood Principal Architect Verity Ultraseek
Re: PaceProfileAttribute
I'm in favor of profiles, just -1 to allowing @profile on sub-elements. So I prefer PaceProfile to PaceProfileAttribute. On Monday, February 7, 2005, at 02:17 PM, James M Snell wrote: This is entirely possible also. Just to be clear tho, you're not -1'ing the idea of profiles, just the allowing of the @profile attribute on sub-elements (e.g. entries contained in feeds) correct? This is an important distinction because I'm definitely not married to the syntax as presented but would definitely like to see us adopt the profile mechanism in general. - James M Snell Antone Roundy wrote: -1: One profile (or maybe set of profiles) per document is better in my opinion. If an aggregator aggregates entries with different profiles, it can either fix them up as needed to conform to a common profile, or if multiple profiles can be specified at the top level, declare the profiles for all of the entries in the document there.
Re: PaceProfile
The specification of multiple profiles is one of the differences between PaceProfile and PaceProfileAttribute. Mark's original proposal does not allow for multiple profiles, mine does. Mark's Proposal: * @profile or modified @version on the document level * one profile per document * profile applies to the entire document * a profile describes what metadata elements are required and cardinality thereof My Proposal: * @profile on the atom:feed / and atom:entry / levels (independent of document arrangement) * multiple profiles per atom:feed / atom:entry / * profile applies just to the atom:feed / or atom:entry / element upon which it appears. it does not apply recursively down the structure. * a profile describes what metadata elements are required and cardinality thereof * profile is strictly informational and does not impose any operational requirements on the part of consumers/producers Mine is admitedly more complex, but it also, in my opinion, provides greater flexibility. Whether that greater flexibility is required is a separate question that is open for debate. WRT multiple profiles, since all a profile is is a statement of which elements are required and the cardinality thereof, the union of the profile requirements is what is expected in the document. For instance, if profileA requires foo / and profileB requires bar /, processors should expect foo / and bar /. The only contention will be if profileA and profileB specify requirements for a different cardinality of some common element. e.g. profileB requires no more than 1 foo / and profileA requires no fewer than 2 foo /. If the element contains 2 foo /, then the processor determines that the element is conformant with profileA, but not profileB. It is up to the processor to figure out what to do in such cases. Alternatively, a rule can be specified that the profile with the highest cardinality for element foo / takes precedence. For interoperability sake, the creation of profiles should have a somewhat high bar. creating another profile that describes exactly what you're after should not be something done willy-nilly if you expect people to have a clue what they're producing/processing. Restricting profiles as we've done, composing multiple well-defined profiles on the fly will be more reliably interoperable than creating a brand new profile to fit some specific situation. Question: If head-in-entry were removed from the spec, could a profile indicate that entry could contain a head that specified the feed data relevant to the entry? I'd be in favor of handling aggregation that way, and would support PaceAggregationInSeparateSpec, and would be happy to drop PaceAggregationDocument and PaceAggregationDocument2 if that were the case. Yes, with either option (PaceProfile or PaceProfileAttribute). - James M Snell Antone Roundy wrote: +1. I may have missed something, but I didn't see it specified whether one document could list more than one profile or not. I think it should not be allowed. With multiple profiles mixed, it would be more difficult to figure out exactly what to expect, and I don't expect it to be necessary--if you want to specify a feed that's a hybrid of two profiles, create another profile that describes exactly what you're after. Profiles could take care of the job of specifying how to create what I recently referred to as Collection Documents and Archive Documents (identical except that multiple versions of a particular entry would be allowed in Archive Documents). I would be fine with dropping PaceArchiveDocument, and allowing content and summary in head (PaceCommentFeeds--let's keep link/@rel=comments though) if this is accepted. Question: If head-in-entry were removed from the spec, could a profile indicate that entry could contain a head that specified the feed data relevant to the entry? I'd be in favor of handling aggregation that way, and would support PaceAggregationInSeparateSpec, and would be happy to drop PaceAggregationDocument and PaceAggregationDocument2 if that were the case.
Re: PaceProfile
-1, I guess. This Pace proposes an organization of the spec which assumes we accept PaceProfileAttribute and/or keep the version attribute. I think the layout is reasonable for that scenario, but it overlaps with PaceExtensionConstruct and some others. I don't really see much reason to do a Pace for this. Perhaps it's meant to counter PaceOrderSpecAlphabetically. I'm not really opposed to either Pace, but these are editorial issues, which the WG can address after the format is locked down. Right now, I feel they are just confusing matters. I think we should close them and deal with this problem around Feb 21ish[0]. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg12981.html
Re: PaceXhtmlNamespaceDiv
Sam Ruby wrote: I can easily sit back and adopt a wait and see and I told you so attitude, but by now it should be obvious that I care too much about the success of this format and protocol to do that. After watching this WG fail to communicate clearly on this matter, and make a variety of arcane XML serialization mistakes in the course of discussion, it's clear to me that Sam is right. +1 to PaceXhtmlNamespaceDiv Robert Sayre
Re: PaceProfile
Actually, PaceProfile was proposed prior to PaceProfileAttribute and is an independent proposal. I offered PaceProfileAttribute as a separate proposal because 1) PaceProfile didn't really specify any specifics for the the @profile attribute beyond suggesting that it be created or that @version be modified and 2) I did not think that a complete restructuring of the document was really necessary. I tried to be more specific in PaceProfileAttribute. I am quite certain that Mark has his own ideas with regards to PaceProfile and that he would not agree that PaceProfile depends on PaceProfileAttribute in any way. Likewise, PaceProfileAttribute has no dependencies on PaceProfile. - James M Snell Robert Sayre wrote: -1, I guess. This Pace proposes an organization of the spec which assumes we accept PaceProfileAttribute and/or keep the version attribute. I think the layout is reasonable for that scenario, but it overlaps with PaceExtensionConstruct and some others. I don't really see much reason to do a Pace for this. Perhaps it's meant to counter PaceOrderSpecAlphabetically. I'm not really opposed to either Pace, but these are editorial issues, which the WG can address after the format is locked down. Right now, I feel they are just confusing matters. I think we should close them and deal with this problem around Feb 21ish[0]. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg12981.html
Re: PaceProfile
James M Snell wrote: I am quite certain that Mark has his own ideas with regards to PaceProfile and that he would not agree that PaceProfile depends on PaceProfileAttribute in any way. Likewise, PaceProfileAttribute has no dependencies on PaceProfile. Oh! This isn't editorial at all, then. I guess I'd have to see some more spec text, then. I'm not sure what Mark is proposing. Robert Sayre
Re: PaceProfile
Robert Sayre wrote: James M Snell wrote: I am quite certain that Mark has his own ideas with regards to PaceProfile and that he would not agree that PaceProfile depends on PaceProfileAttribute in any way. Likewise, PaceProfileAttribute has no dependencies on PaceProfile. Oh! This isn't 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
Re: PaceProfile
-1 because it is incomplete (no text for the new profiles in Section 6). The specification of those profiles could have a major technical effect on the rest of the document. --Paul Hoffman, Director --Internet Mail Consortium
PaceProfileAttribute
-1 because it doesn't feel like it belongs in the core. That is, when more developers have real profiles that they want to differentiate from the atom core, adding a @profile attribute seems like a good extension. --Paul Hoffman, Director --Internet Mail Consortium
withdraw PaceFeedRecursive
Please withdraw PaceFeedRecursive because forcing everything to be an entry is sufficient justification to forbid inclusion by anything other than reference. The other (still needed) bits are in PaceHeadless. Cheers, Roy T. Fieldinghttp://roy.gbiv.com/ Chief Scientist, Day Software http://www.day.com/
Re: PaceProfile
On Monday, February 7, 2005, at 03:41 PM, Sam Ruby wrote: Robert Sayre wrote: James M Snell wrote: I am quite certain that Mark has his own ideas with regards to PaceProfile and that he would not agree that PaceProfile depends on PaceProfileAttribute in any way. Likewise, PaceProfileAttribute has no dependencies on PaceProfile. Oh! This isn't 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. Please finish it! If it turns out close to the way I understand it from what's already there and the discussion thus far, it will keep my support.
Re: PaceXhtmlNamespaceDiv
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 anyway. Same here: -1 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Service Constructs?
Looks like we forgot to write a formal Pace for removing the protocol elements. Proposed by Julian: http://www.imc.org/atom-syntax/mail-archive/msg12887.html +1s from Sayre, Bray, Gregorio. Less positive comments from Hoffman and Underwood. Robert Sayre
Re: PaceProfileAttribute
Paul Hoffman wrote: -1 because it doesn't feel like it belongs in the core. That is, when more developers have real profiles that they want to differentiate from the atom core, adding a @profile attribute seems like a good extension. Hmm. the challenge with this assertion is that the atom spec as it stands today, does not give someone the option of being able to override the metadata containment requirements as specified by the core. Nor does it give any indication how such redefinition should occur. This spec does not introduce any other profiles, it just provides the framework under which profiles can be created and cooks that into the core so that doing so can be done in a consistent, reliable manner. Further, one would need to consider how a @profile differs from a @version and the namespace attribute, etc. This proposal replaces @version completely with the @profile mechanism. The namespace is used to identify the semantics of the individual elements themselves while the profile is used to identify the containment requirements. As the spec stands currently, the relationship between atom [EMAIL PROTECTED] requirements+element semantics is muddled up. Is it possible for someone to modify containment requirements for a specific use case while adhering to the same atom namespace? The @version attribute is defined such that it relates to Atom spec version. Does @version reflect element semantics or containment requirements or both? This proposal says, namespace==element semantics, @profile=containment requirements and provides a clear, consistent approach to handling different/multiple @profiles. That is a far cry from the minimal and far-from-helpful atom:feed elements MUST have a version attribute whose content indicates the version of the Atom specification that the feed conforms to. The content of this attribute is unstructured text. Also, as others have pointed out, the profile attribute mechanism could be used to handle cases such as defining the requirements for an archive as opposed to creating a new top level archive element. Bottom line: while @profile COULD be added as an extension, I think it is much more valuable in the core as a replacement to @version. - James M Snell
Re: Service Constructs?
+1 on this also. They shouldn't be in the core - James M Snell Robert Sayre wrote: Looks like we forgot to write a formal Pace for removing the protocol elements. Proposed by Julian: http://www.imc.org/atom-syntax/mail-archive/msg12887.html +1s from Sayre, Bray, Gregorio. Less positive comments from Hoffman and Underwood. Robert Sayre
Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder]
On Feb 6, 2005, at 6:50 PM, Mark Nottingham wrote: On Feb 5, 2005, at 6:01 PM, Roy T.Fielding wrote: The problem with that statement (about HTTP) is that absence of a must-understand in HTTP is not one of its big problems. Yes, I know lots of people have talked about it as a limiting factor in the syntax of HTTP, but to call it an actual problem would say that it prevented some good from being accomplished. It arguably tipped some people towards SOAP when HTTP would have been adequate. That's not a prevention of good, but we've already seen enough fragmentation in the syndication world. Well, arguably, those same applications should have been tipped into the waste basket in the first place. But I don't think you followed my main point: must understand is a mechanism to enable fragmentation -- its very presence leads away from standardization. Lack of mU is one of the reasons that HTTP is not fragmented (along with me being a stubborn pain in the ass). Hence, it is only a problem for some applications that were of questionable character, and it remains unclear whether HTTP would have benefitted by having a mU feature or if its presence would have led to a complete meltdown. Things that a syndication format might want to make mandatory are copyright controls and micropayments, but both have been shown in practice to require either a willingness on the part of the recipient to accept that specific restriction (i.e., human intervention and understanding) or forceful requirement by the sender (i.e., encryption). In both cases, agreements have to be established with the user in advance, before they even receive the content, and thus do not need a must understand feature. I don't think mU is intended for such things; rather, the case for mU could be characterised as extensions that change the operation of the protocol in a manner that renders it useless or misleading to try to use the feed if you don't know what to do with the extension. It's advisory. Right, but look at my examples and try to think of any others that would require changes in operation on the behalf of recipients. There may be others, but I am not aware of any more. In fact, must understand has no value in a network-based application except as positive guidance for intermediaries, which is something that can still be accomplished under mustIgnore with a bit of old-fashioned advocacy. So, if I can restate your position, you're saying that you don't dispute that understanding some extensions may be required, but that it isn't necessary to make that visible to the processor, because it'll be co-ordinated beforehand (e.g., through market forces, out-of-band-communication), correct? No, my position is that it isn't necessary to include mU in the format. Within the control data of an interaction protocol, sure, but not within the payload of completed actions, wherein any such requirements are far too late and susceptible to abuse. Just to be clear that I am not completely against mU in all protocols, that feature does exist in waka because it is useful when talking through intermediaries. Roy
Re: PaceProfile
Profiles seem to be a way for people who disagree with decisions made by this working group to invent their own Atom format and claim it is valid Atom. No thank you. -1 Graham
PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready
Henry Story wrote: I think that the complexity that this proposal is proof of its failure. If you look at a Feed document as simply a sliding window view into the historical state of entries instead a sliding window view into the current state of entries (though as I have shown these can overlap),` then you have your archive document already. Choice of model will not make an iota of difference to the core spec. I could sit here and claim that sliding window makes reordering impossible - that would be about as jaundiced and prejudicial a view as I've seen spat out about current state. What good is this doing? Can we please desist from arguing over models? Five years out we can determine if there is a sufficiently powerful model to explain syndication based on the data. Not now. cheers Bill
Re: PaceProfile
Graham wrote: Profiles seem to be a way for people who disagree with decisions made by this working group to invent their own Atom format and claim it is valid Atom. No thank you. I'm not sure they are that antagonistic, but I agree with Paul when he says they could be added later. If profiles aren't supposed to matter to Core Atom processors, why not put our money where our mouth is and make profiles declare themselves in their own namespace? Robert Sayre
Re: PaceXhtmlNamespaceDiv
I'm +1 when wearing my aggregator hat, and indifferent from a publishing perspective. -- Roger Benningfield JournURL
