Discussion on whether or not to make the id attribute in <entry> an xsd:ID
[JamesSnell] In the schema, the id attribute is defined as an xsd:ID so it is an ID in the technical XML sense. This has the double effect of allowing entries to be referenced directly using the URI#id scheme which makes XML digital signatures and other interesting types of things easier (without an id attribute, we'd have to use XPath mapping to directly identify a given entry within a document). Sure, it is a bit limiting, but it has its uses.
[AaronSw] Consensus seems to be that ID should be a URI, which is definitely not an xsd:ID. (Neither are integers, which seems to be the other possibility.)
[AsbjornUlsberg] What "consensus"? In all uses of XML, an xsd:ID will be much more useful than an URI. If I understand you correctly, the ID should be built up by the URL of the website, plus an internal identifier for the entry. If the URL of the website changes, then the ID won't be right anymore. Either, the ID will change (and break the logic of an ID following an entry wherever the entry exists), or the ID won't contain the same URL as the feed itself. It's better to give each entry an internal unique xsd:ID, that when combined with the feed's URL, gives you an global unique identifyer.
[JamesSnell] Ok, consider this. The <entry> entry-id as far as the conceptual model of a WellFormedEntry is concerned is related as an Element. The <entry> id as far as having a technical reference point for things like digital signatures, URI addressing of specific <entry> element references would use an attribute. <entry-id> is a URI that identifies the WellFormedEntry. the id attribute is an XML ID that identifies a specific serialization of the WellFormedEntry. Would that clear up the issue? I've updated the example to reflect this approach
[AaronSw] I don't want to name the id element entry-id, because a) it's already (duh) in an <entry>, and b) it prevents the same element from being reused. I'm wary about adding a per=element ID because it would really have to be required to be useful, and it's difficult to do right and we already have an ID (although it's funky)... Hm, this is complicated.
[JamesSnell] But it is an ID with different semantics... one relating to the conceptual entry, the other relating to the specific individual serialization of it. They serve two distinct purposes. I'm not as concerned about what they are named as much as I am about having the ability to directly reference, on a technical level, an individual <entry> element independent of it's semantic ID.
[DonPark] It is a mistake to overload 'id' attribute with semantics deviating from xsd:ID. Adding a prefix to the name like 'entry' makes sense.
[BillDehora] Add me to Aaron's consensus - I don't like the idea of baking xsd types into id. And the locator-id thing is old permathread ground. A entry can have a locator distinct from its identifier. To my mind they're both URIs and if they happen to be same, that's cool.
[MartinAtkins] If we want to decrease verbosity, maybe we can allow the per-entry ids to optionally be relative URLs of a URL given just once in the document. This way there'd be less repeated http://www.mysite.com/blog/entries/ which would save quite a lot of bandwidth, I'd hazard.
It needs to be optional, though, because if it isn't it becomes impossible to re-syndicate multiple feeds in aggregate form. An example of this is the LiveJournal 'friends page' which has entries from several different 'blogs' each with its own base URL, but there are certainly other feeds right now which exist as an aggregate of others although admittedlyI cannot name one off the top of my head. (in RSS, this aggregation is often painful, but Echo or whatever would make it a lot cleaner)
[JeremyGray] I am generally against using a document-relative identifier such as xsd:ID for the simple reason that it will start to fall down (or at least become confusing) when entries are considered outside of instance documents (e.g. when in persistence mechanisms such as databases) and in actual syndication (as opposed to publishing) scenarios. For that reason, I would argue for a globally unique identifier for each entry, and will stand by that regardless of any future conclusions regarding the type of identifier, its expected retrievability, the expected results of an retrieval, etc.