Re: some minor 0.2 corrections

["Aaron Swartz" <me@xxxxxxxxxxx>]

> > What should clients do when they see a new version?
> Behave according to the spec defined for that version.

They can't do that; the version wasn't out when they were written.

> > What if it's embedded in another XML format and doesn't have an 
> > attached version number?
> The handling will primarily be defined by that other format - i.e. 
> it's out
> of scope.

Huh? So HTML, the API, and every other conceivable place the format 
could be embedded needs to reiterate everything in our spec?

> > Until these kinds of questions are answered, the version attribute 
> > seems to be more like
> > superstition than a technical decision.
> We could wait until there was a change, then add the version number, 
> but
> tools designed for the current version would choke on the newer 
> syntax...
> Are you suggesting that the format will *never* change?

No, I'm suggesting that if we're considering having serious 
backwards-incompatible changes with required behavior that needs to be 
triggered by a version attribute on the feed element, we need to 
describe exactly what that behavior is in the spec. If we're not 
considering that, then I'd like to hear a justification for the version 
element.

> > > Interesting, but I'd be tempted to drop the mode altogether (i.e. 
> > > always XML) and let the XML describe what's in it.
> If the content can go in the XML of this feed, it can surely go in data
> nested inside the feed - what's the difference?

Can you give an example of what you mean?

> What is the relationship between feed and entry? Between entry and 
> content?

entry and content  respectively. The things they point to don't have 
rdf:types.

> I guess it would validate if you made entry a property, but that 
> conflicts
> with the notion of giving entries URIs.

How?
--
Aaron Swartz: http://www.aaronsw.com/