Wednesday, August 10, 2005, 1:34:44 AM, Tim Bray wrote:
> The problem could hypothetically arise when someone extracts > properties from the foreign markup, stuffs them in a tuple store, and > then when the software that knows what to do with comes along and > retrieves it and recognizes the relative URI and can't do much > because the base URI is lost. I expect that many Atom Protocol server implementations will work this way. > So... IF you know how to handle some particular extension, AND IF you > expect to handle it when the extension data has been ripped out of > the feed and stored somewhere without any context, THEN you shouldn't > use a relative reference. The 1st/2nd "you"s are likely to be a different person from the 3rd "you". You seem to be saying: "if the consumer knows how to handle some particular extension [...] then the producer shouldn't use a relative reference". How does the producer know what the consumer will do? (Well of course that is the job of the specification, which is my point here). > Alternatively, IF you want to empower extensions to process they > data they understand, AND IF you want to rip that data out of the > feed and store it somewhere, THEN it would be smart to provide > software an interface to retrieve context, such as feed-level > metadata and the base URI. It sounds like you disagree with the rationale for Simple vs Structured extensions in [1]. So can I ask you why you think Atom defines Simple and Structured Extensions, when according to your understanding they need to be processed in exactly the seem way (though simple aren't language sensitive - which seems a bit odd if you believe that). I think that the second paragraph of 6.2.1 is pretty clear about what Simple Extensions mean (the value range of the property is character data, not character data plus base URI and language context), and that base URIs would be irrelevant to their processing, but I thought that it might need some clarification as once people start using them for URIs there is a risk that people could start using them for relative refs, given the lack of explanation or rationale for their purpose. > Sounds like implementor's-guide material to me. Alternative 1 is not implementable, and alternative 2 suggests processing that is not compatible with the intended purpose of Simple Extension elements. I wasn't entirely convinced that we needed to add this clarification, but now I am sure that we do. If there is a belief that implementations SHOULD preserve the base uri of Simple Extensions then we need to indicate that this is not true, else Simple Extensions will be broken from the start. [1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html -- Dave
