Re: More about Extensions
I said: > I might have misinterpreted your comment, but I'm arguing with Tim for > saying that SEE's CAN contain relative refs and no clarifification is > needed, and with you for saying that SEE's CANNOT contain relative > refs and no clarification is needed. There's a word for that :) I oversimplified that. What I really meant is not that rel refs are banned, but that publishers should not expect rel refs to be processed differently than strings. The value of a Simple Extension is a string. It is the job of an unextended Atom implementation to transfer those strings. Extensions can encode what they like in those strings, and if the extension is supported by the receiver, then it can be decoded. A publisher can put numbers, dates, URIs, or escaped XML in one of these string; they can even put relative refs in there, but they must only expect the string to be preserved, not the context of the surrounding XML. SEE's exist so that simple properties can be transfered without requiring that the CMS store an Infoset equivalent. -- Dave
Re: More about Extensions
Wednesday, August 10, 2005, 11:12:30 PM, you wrote: > Dave: I think I see what you're getting at... correct me if I'm wrong. > So I decide that my aggregator is going to look for unknown Simple > Extensions in Atom feeds and display them as a table of name/value > pairs at the bottom of every entry. And during the display process, > I'm going to run a regex over the values and linkify any URLs I find. > When someone's relative references just sit there as plain text and I > get a complaint, who's to blame? Another example is: An AtomPP client publishes entries to an AtomPP server. The server stores the entries in a CMS. The CMS publishes the entries as an Atom feed. The CMS shouldn't have to preserve the value and base URI for each extension attribute. Simple Extensions were designed with this sort of scenario in mind. > (1) Me, for trying to provide generic support for unknown extensions? > (2) The publisher, for failing to consider non-specific or limited > support of the extension? > (3) The complaining user, for expecting too much? > If it's (3), then I agree with Tim... the spec says what it says, and > that's fine. Otherwise, there may be a legitimate problem here. Well I think that it can't be (1). We wouldn't have wrote section 6.4.1 and 6.4.2, if we didn't want to support this. It shouldn't be (3) either. If the publisher puts something into an Atom document, it shouldn't be ambiguous whether it is a URIRef or not, even for extensions. This is what I mean by extensions being part of the Atom model. We wouldn't have banned Simple Extensions from containing language sensitive text, if we were requiring implementations to preserve each of their base URIs. This paragraph explains that, but obviously not well enough: > The element can be interpreted as a simple property (or name/value > pair) of the parent element that encloses it. The pair consisting of > the namespace-URI of the element and the local name of the element > can be interpreted as the name of the property. The character data > content of the element can be interpreted as the value of the > property. If the element is empty, then the property value can be > interpreted as an empty string. I'm requesting that some clarification be added specific to relative refs. -- Dave
Re: More about Extensions
Wednesday, August 10, 2005, 11:33:46 PM, Robert Sayre wrote: > On 8/10/05, David Powell <[EMAIL PROTECTED]> wrote: >> I think that it is pretty clear, but as Tim disagrees, I think that >> this is a good indication that we need clarification. > I think it's good indication that you've argued with everyone, no > matter what they say. I'm strongly opposed to adding anything like > you're suggesting. Tim and I agree that the current text is > sufficient. There's a word for that. I might have misinterpreted your comment, but I'm arguing with Tim for saying that SEE's CAN contain relative refs and no clarifification is needed, and with you for saying that SEE's CANNOT contain relative refs and no clarification is needed. There's a word for that :) -- Dave
Re: More about Extensions
On 8/10/05, David Powell <[EMAIL PROTECTED]> wrote: > I think that it is pretty clear, but as Tim disagrees, I think that > this is a good indication that we need clarification. I think it's good indication that you've argued with everyone, no matter what they say. I'm strongly opposed to adding anything like you're suggesting. Tim and I agree that the current text is sufficient. There's a word for that. Robert Sayre
Re: More about Extensions
Dave: I think I see what you're getting at... correct me if I'm wrong. So I decide that my aggregator is going to look for unknown Simple Extensions in Atom feeds and display them as a table of name/value pairs at the bottom of every entry. And during the display process, I'm going to run a regex over the values and linkify any URLs I find. When someone's relative references just sit there as plain text and I get a complaint, who's to blame? (1) Me, for trying to provide generic support for unknown extensions? (2) The publisher, for failing to consider non-specific or limited support of the extension? (3) The complaining user, for expecting too much? If it's (3), then I agree with Tim... the spec says what it says, and that's fine. Otherwise, there may be a legitimate problem here. -- Roger Benningfield
Re: More about Extensions
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
Re: More about Extensions
Wednesday, August 10, 2005, 1:30:54 AM, Robert Sayre wrote: > On 8/9/05, David Powell <[EMAIL PROTECTED]> wrote: >> >> Publishers should expect that relative refs used in atom:link will >> work, but publishers should expect that relative refs used in Simple >> Extensions will break. > Disagree. We have no idea what people will do with this, or where they > will be deployed. You're suggesting adding implementation advice, > since the content of a simple extension element is not defined as a > URI reference. I want to know whether an implementation is corrupting data if it discards the base-uri of simple extensions. I think that it is the job of the spec to tell me this, not the the job of "implementation advice" to decide this. > By your logic, we have to explicitly clarify that > atom:updated is not subject to xml:base processing. Sorry, I strongly > disagree. Are you saying that we don't need clarification because it is obvious that simple extensions only contain strings that aren't subject to base processing? I think that it is pretty clear, but as Tim disagrees, I think that this is a good indication that we need clarification. -- Dave
Re: More about Extensions
Sorry to note the obvious, but does this not sound so much like a good reason we should have engineered atom to *be* RDF? Is this not exactly one of the many problems that RDF sets out to solve? Henry Story On 10 Aug 2005, at 02:34, Tim Bray wrote: On Aug 9, 2005, at 5:11 PM, David Powell wrote: No, we just need to warn publishers (and extension authors) that the base URI of Simple Extension elements is not significant, and that they must not expect it to be preserved. Either the software understands the foreign markup, in which case it might recognize a relative URI, in which case it should apply the correct base URI, or it doesn't, in which case everything in the foreign markup is just a semantics-free string. 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. 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. 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. Sounds like implementor's-guide material to me. And, to whoever said relative references are "fragile": Wrong. When you have to move bales of web content around from one place to another, and just supposing hypothetically that you have internal links, relative references are robust, absolute URIs are fragile. - Tim
Re: More about Extensions
Tim Bray wrote: Sounds like implementor's-guide material to me. 1 - James
Re: More about Extensions
On 8/9/05, Tim Bray <[EMAIL PROTECTED]> wrote: > And, to whoever said relative references are "fragile": Wrong. When > you have to move bales of web content around from one place to > another, and just supposing hypothetically that you have internal > links, relative references are robust, absolute URIs are fragile. And when you have bales of web content that have to be displayed on a super-wide variety of display technologies, many of which have limited supported for changing and mixing base URIs (like HTML), relative references are fragile. This is the kind of situation you run into with syndication formats, and it should go in the implementation guide. Robert Sayre
Re: More about Extensions
On 8/9/05, David Powell <[EMAIL PROTECTED]> wrote: > > Publishers should expect that relative refs used in atom:link will > work, but publishers should expect that relative refs used in Simple > Extensions will break. Disagree. We have no idea what people will do with this, or where they will be deployed. You're suggesting adding implementation advice, since the content of a simple extension element is not defined as a URI reference. By your logic, we have to explicitly clarify that atom:updated is not subject to xml:base processing. Sorry, I strongly disagree. Robert Sayre
Re: More about Extensions
On Aug 9, 2005, at 5:11 PM, David Powell wrote: No, we just need to warn publishers (and extension authors) that the base URI of Simple Extension elements is not significant, and that they must not expect it to be preserved. Either the software understands the foreign markup, in which case it might recognize a relative URI, in which case it should apply the correct base URI, or it doesn't, in which case everything in the foreign markup is just a semantics-free string. 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. 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. 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. Sounds like implementor's-guide material to me. And, to whoever said relative references are "fragile": Wrong. When you have to move bales of web content around from one place to another, and just supposing hypothetically that you have internal links, relative references are robust, absolute URIs are fragile. -Tim
Re: More about Extensions
Tuesday, August 9, 2005, 11:22:14 PM, Robert Sayre wrote: > What are we going to do, outlaw strings that happen to look like > relative references? No, we just need to warn publishers (and extension authors) that the base URI of Simple Extension elements is not significant, and that they must not expect it to be preserved. We do the same regarding xml:lang already by saying that the element is not Language Sensitive, which means that the language context is not significant and that publishers must not expect it to be preserved. from Section 2: > The language context is only significant for elements and attributes > declared to be "Language-Sensitive" by this specification. I'd suggest adding something similar to Section 6.4.1, eg: "The base URI is not significant for Simple Extension elements." > Relative references are fragile, and people understand why they > break. Publishers should expect that relative refs used in atom:link will work, but publishers should expect that relative refs used in Simple Extensions will break. -- Dave
Re: More about Extensions
On 8/9/05, David Powell <[EMAIL PROTECTED]> wrote: > If I'm wrong, and the rationale behind Simple Extensions isn't > important... Sorry, I don't buy this. You're wrong, but the rationale is important. :) What are we going to do, outlaw strings that happen to look like relative references? If you want a generic processor to handle your extension, you've got atom:link, which will work fine. Maybe you want the relative reference to point at something relative, no matter where it ends up. I can't think of why anyone would want to do that, but maybe they will. Relative references are fragile, and people understand why they break. None of the other pros for this capability are affected. Robert Sayre
More about Extensions
I still believe that relative URIs shouldn't exist in Simple Extension constructs [1]. I think that the lack of rationale for their being 2-3 classes of extension construct is proving to be harmful. Prior to the introduction of Section 6, Atom pretty much said you can include any foreign markup anywhere. I thought that this conflicted with the claim made by the charter that: > Atom consists of: > * A conceptual model of a resource > * A concrete syntax for this model I thought that the model should be separable from the syntax, so that people can use databases and RDF stores as their back-ends rather than just XML files. And I thought that it was important that extensions should be part of that model, rather than only be representable in the syntax, else extensions would be poor-cousins of the core elements. Restricting Atom extensions to only being simple string name/value parameters would ensure that they were represented in the model, but it would have been too limiting. So the two classes of Extension construct, Simple and Structured, are a compromise between constraints and flexibility. The pros and cons of each class are: Simple Extension constructs: + simple string name/value properties of the feed/entry/person. Easy to implement generically end-to-end in servers/clients so that extensions can be deployed generically without requiring "boil the ocean" acceptance. + property semantics as described by section 6.4.1. + publishing clients could provide an extension editor, where metadata fields could be added to the clients form, given a namespace URI and element name. + extensions don't need to be defined specifically for Atom. RDF Vocabularies, RSS extensions, DC, and PRISM already define properties that are compatible with Atom Simple Extensions. + simple, useful mapping to RDF - can't represent language sensitive text. This decision was made because very few RSS extensions contain language sensitive text, (they tend to contain dates, numbers, tokens, URIs etc - when language-sensitive text is required Structured Extensions should be used). Also, the barrier for implementations such as custom property tables, CRMs, and WebDAV implementations would be high. - can't represent relative URI references, because they are defined to be strings only, and generic implementations can't know what is or isn't a URI reference. Structured Extension constructs: + Can support (almost) arbitrary XML. - no pre-defined semantics. + no pre-defined semantics. - clumsy generic mapping to RDF (by preserving the XML blob), though with extension specific knowledge a better mapping could be used. + Publishing servers can generically support them by preserving the blob of XML. - Publishing clients can't easily generically support them, as the UI to edit a chunk of arbitrary XML wouldn't be very user-friendly. - require at least a mandatory attribute or child in order to exist. Namespaced attributes & atom:link children -- - Not part of the Atom model - only representable by the syntax. - Not really practical to support generically; require "boil the ocean" adoption. - Really not something I'm keen on as evidenced by this biased assessment... Are they really allowed for things other than future versions of Atom? + ...OK, they let you add annotations to elements in a way that would be difficult to address without an RDF style graph-based format. Does that sound about right? So, can we agree that relative URIRefs aren't allowed in Simple Extension constructs and add a clarification, else their implementation won't satisfy the rationale for their design. If I'm wrong, and the rationale behind Simple Extensions isn't important, then can someone explain why there are two classes of extension? [1] http://www.imc.org/atom-syntax/mail-archive/msg16598.html -- Dave
