Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Too terse - I don't understand why you're asking this. But if you really think that we allow everything we don't ban, we should say that somewhere in the spec. hmm. I could write that Pace if you want, but maybe it would be more productive to explain why you find my interpretation psychotic. Because it's an interpretation that cares not for others. I could ask if you could maybe explain why that was more a productive direction, but isn't this getting silly now? Maybe you could point to some spec text to back up your opinion. Postel's law. MarkN seems to think its only this or other IETF working groups that can extend the Atom namespace. I don't see anything in the spec about that. Let's agree I made an error of judgement in my characterisation and call your interpretation something neutral instead - interpretation-x. As I've withdrawn 'psychotic' I think it's reasonable to say we can stop quibbling and move on. The point remains - if you think interpretation-x is valid way of systematically evaluating the spec, then there is room to discuss whether we should make mention of it. Will you address now whether we should mention or approve that interpretation in the spec? cheers Bill
Re: extensions -- Atom NS and unprefixed attributes
Tim Bray wrote: On May 15, 2005, at 9:43 PM, Robert Sayre wrote: evilExtension / Legal? Which part of the spec rules it out? No part. Per http://www.atompub.org/2005/04/18/draft-ietf-atompub-format -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules for how to handle it, right? Yes, there are clear parsing rules. What's the benefit of allowing such markup? The benefit the Web derived from HTML's implicit-but-universally-implemented MustIgnore rule; it introduced enough slack into the system that people could experiment without breaking things. Related resource: http://www.webratio.com/images/20050408Bosworth.pps More generally: ruling things out should be avoided unless (a) you're really sure they're harmful and (b) you think you can actually successfully enforce it. -Tim A concrete example of the implications of such a rule: http://diveintomark.org/archives/2003/04/13/object_and_internet_explorer ... in particular, follow this link: http://www.robinlionheart.com/stds/html4/objects.html The only way that authors of future revisions of the specification can be confident that they are adding things that don't break anything is if either (1) some names (e.g., the atom namespace) are reserved for such things, or (2) all future additions go into new namespaces. I do believe that schemas and/or the feedvalidator can enforce such a rule. And I don't believe that a requirement that people who wish to extend Atom do so in their own namespace is overly burdensome. - Sam Ruby
Re: extensions -- Atom NS and unprefixed attributes
On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote: The benefit the Web derived from HTML's implicit-but-universally-implemented MustIgnore rule; it introduced enough slack into the system that people could experiment without breaking things. Don't you think the Feed Validator should flag my example as invalid? Robert Sayre
Re: extensions -- Atom NS and unprefixed attributes
On Monday, May 16, 2005, at 10:59 AM, Tim Bray wrote: On May 16, 2005, at 6:27 AM, Robert Sayre wrote: On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote: The benefit the Web derived from HTML's implicit-but-universally-implemented MustIgnore rule; it introduced enough slack into the system that people could experiment without breaking things. Don't you think the Feed Validator should flag my example as invalid? No. I actually thought that what we meant was what the spec said, and that this was the (very reasonable) outcome of our discussion on MustUnderstand. That means that if the IETF wants to extend Atom, we can do it as long as the extensions can be safely ignored. If you want to put something new in that can't be safely ignored, the whole document namespace has to be changed. I thought that the WG had converged on a reasonable and in fact enlightened position and I really would prefer not to go back and repeat the discussion. -Tim I would think that a warning in that case would be useful that case, since it might be an accidental error--forgetting to prefix an extension element, or misspelling the name of an Atom element. Something along the lines of Warning: this element is not recognized by the validator as a member of the Atom namespace. It may be from a newer version of the Atom specification than the validator is aware of, or it may be an error.
Re: extensions -- Atom NS and unprefixed attributes
On 16 May 2005, at 5:59 pm, Tim Bray wrote: i) Don't you think the Feed Validator should flag my example as invalid? No. ii) I actually thought that what we meant was what the spec said, and that this was the (very reasonable) outcome of our discussion on MustUnderstand. That means that if the IETF wants to extend Atom, we can do it as long as the extensions can be safely ignored. If you want to put something new in that can't be safely ignored, the whole document namespace has to be changed. I thought that the WG had converged on a reasonable and in fact enlightened position and I really would prefer not to go back and repeat the discussion. -Tim Extensions being safely ignored is not the same thing as random crap in the Atom namespace. Robert's example was bogus in this regard, since there's no such thing as an evil extension. On the other hand, I can't see any reason to allow third parties to create extensions in the atom namespace, other than to create problems for ourself when it come to v1.1. Graham
Re: extensions -- Atom NS and unprefixed attributes
On May 16, 2005, at 10:44 AM, Robert Sayre wrote: I am not looking for a repeat of that discussion. Atom 1.0 Processors cannot distinguish between markup added later on by the IETF and markup added by a third party, so the processing rules must remain as they are. That doesn't mean we should allow anyone and everyone to add elements and attributes to the Atom namespace. My problem is that putting text in the format spec saying Nobody but the IETF can extend the namespace feels empty and useless, are we going to send Marshall Rose over to beat up anyone who tries? It's like clauses in constitutions saying this clause can't be amended, well yes it can and will be if enough people want it to. I guess staking the claim is not actively harmful. FWIW I don't recall ever seeing such language in any other specs, but maybe I just wasn't looking. -Tim
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote: My problem is that putting text in the format spec saying Nobody but the IETF can extend the namespace feels empty and useless, are we going to send Marshall Rose over to beat up anyone who tries? It will happen and we won't be able to stop it. I have a question - what's the problem? cheers Bill
Re: extensions -- Atom NS and unprefixed attributes
Tim Bray wrote: On May 16, 2005, at 10:44 AM, Robert Sayre wrote: I am not looking for a repeat of that discussion. Atom 1.0 Processors cannot distinguish between markup added later on by the IETF and markup added by a third party, so the processing rules must remain as they are. That doesn't mean we should allow anyone and everyone to add elements and attributes to the Atom namespace. My problem is that putting text in the format spec saying Nobody but the IETF can extend the namespace feels empty and useless, are we going to send Marshall Rose over to beat up anyone who tries? It's like clauses in constitutions saying this clause can't be amended, well yes it can and will be if enough people want it to. I guess staking the claim is not actively harmful. FWIW I don't recall ever seeing such language in any other specs, but maybe I just wasn't looking. -Tim http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.5: Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the DAV namespace MUST NOT be used in the request or response body of a versioning method unless that XML element is explicitly defined in an IETF RFC. This hasn't been always succesfull, but at least the Working Group can point people to that section in case they try (and they try quite often :-). Best regards, Julian
Re: extensions -- Atom NS and unprefixed attributes
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Robert Sayre wrote: On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote: My problem is that putting text in the format spec saying Nobody but the IETF can extend the namespace feels empty and useless, are we going to send Marshall Rose over to beat up anyone who tries? It will happen and we won't be able to stop it. I have a question - what's the problem? I can think of a couple things. One would be collisions (which Sam mentioned). Another would be that validators couldn't catch typos. entry... summaryMy trip.../summary contenMy trip to the beach/conten links href=http://example.org; /entry Robert Sayre
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Robert Sayre wrote: On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote: My problem is that putting text in the format spec saying Nobody but the IETF can extend the namespace feels empty and useless, are we going to send Marshall Rose over to beat up anyone who tries? It will happen and we won't be able to stop it. I have a question - what's the problem? I can think of a couple things. One would be collisions (which Sam mentioned). I don't understand- maybe I'm looking at the wrong post? http://www.imc.org/atom-syntax/mail-archive/msg15236.html Another would be that validators couldn't catch typos. Validators won't be able to catch typos for optional markup. cheers Bill
Re: extensions -- Atom NS and unprefixed attributes
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: I can think of a couple things. One would be collisions (which Sam mentioned). I don't understand- maybe I'm looking at the wrong post? http://www.imc.org/atom-syntax/mail-archive/msg15236.html Sam is saying that the IETF can't add a new element to the Atom namespace and be sure there would be no collision. Another would be that validators couldn't catch typos. Validators won't be able to catch typos for optional markup. What do you mean? The extended example in the spec has a generator element. The RNC has caught me adding an attribute called 'url'. Robert Sayre
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: I can think of a couple things. One would be collisions (which Sam mentioned). I don't understand- maybe I'm looking at the wrong post? http://www.imc.org/atom-syntax/mail-archive/msg15236.html Sam is saying that the IETF can't add a new element to the Atom namespace and be sure there would be no collision. I still don't understand. Can't the IETF read their own specs? Another would be that validators couldn't catch typos. Validators won't be able to catch typos for optional markup. If there is a non-optional piece of markup expected, and you enter a typo instead of it, it won't be in the markup, then a validator won't find it, hence the validator will flag that something is missing. What do you mean? The extended example in the spec has a generator element. The RNC has caught me adding an attribute called 'url'. Can validators catch typos or not? You seem to be saying they can't, but they did catch you adding an attribute called url. I'm honestly not getting the gist of this issue, sorry. cheers Bill
Re: extensions -- Atom NS and unprefixed attributes
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: I can think of a couple things. One would be collisions (which Sam mentioned). I don't understand- maybe I'm looking at the wrong post? http://www.imc.org/atom-syntax/mail-archive/msg15236.html Sam is saying that the IETF can't add a new element to the Atom namespace and be sure there would be no collision. I still don't understand. Can't the IETF read their own specs? The spec allows anyone to add stuff to the Atom namespace, so the IETF will have to read everyone's documents before they add something to the Atom namespace. Maybe you folks are implying that collisions just aren't a problem. Can validators catch typos or not? You seem to be saying they can't, but they did catch you adding an attribute called url. I'm honestly not getting the gist of this issue, sorry. If anyone can add unqualified attributes, how can the validator distinguish between a typo and an extension? Robert Sayre
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: I can think of a couple things. One would be collisions (which Sam mentioned). I don't understand- maybe I'm looking at the wrong post? http://www.imc.org/atom-syntax/mail-archive/msg15236.html Sam is saying that the IETF can't add a new element to the Atom namespace and be sure there would be no collision. I still don't understand. Can't the IETF read their own specs? The spec allows anyone to add stuff to the Atom namespace, so the IETF will have to read everyone's documents before they add something to the Atom namespace. The spec does no such thing; that's a psychotic interpretation at best. If people are going to add stuff to the Atom namespace, then they're going to add stuff to the Atom namespace, irrespective of what the spec says. Your options are to live with that or enforce the building of machinery that will reject the markup of people who do it. To build that machinery you'll have to have an ability to proof-check the markup. To proof-check the markup you have to have to ensure its legal names and their combinations can be enumerated at design time - at a minimum. Maybe you folks are implying that collisions just aren't a problem. If they are a problem, then they're universal to XML+namespaces. I'll argue we're not hear to solve that (possible) problem, even if we are responsible for choosing that technology to begin with. One approach for minimising honest-john name collisions for attributes is to state that further added attributes be namespace qualified. If we are still worried about unprefixed attributes, we can either ban them all except for the ones we have designed, or ban them all and place the ones we have inside the atom namespace. Either way, no further unprefixed attributes will be accepted by validators than the ones we mandate now. I suppose if we're going to worry about this stuff, let's worry about these too: - will it be hard for people to use atom attributes outside atom? - will adding new attributes result in spec combination breakage a la the recent situations with new xml:* attributes? [But personally speaking, I find this debate unimportant compared to consequences of say default namespaces and the introduction of xhtml:div] Can validators catch typos or not? You seem to be saying they can't, but they did catch you adding an attribute called url. I'm honestly not getting the gist of this issue, sorry. If anyone can add unqualified attributes, how can the validator distinguish between a typo and an extension? For non-optional attributes, a validator will pick up on a typo to non-optional attribute by way of the non-optional attribute not being there. * Optional attributes can't easily be distinguished because you can't enumerate all of them in advance - formally, that would be a non-existence of bugs class problem. But as they're optional, it's not a disaster. If it is a disaster, we have a design problem first and foremost, not a validation problem. cheers Bill * barring statistically unfortunate events like a typing an attribute in once mistakenly and then typing it in correctly.
Re: extensions -- Atom NS and unprefixed attributes
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: The spec allows anyone to add stuff to the Atom namespace, so the IETF will have to read everyone's documents before they add something to the Atom namespace. The spec does no such thing; that's a psychotic interpretation at best. What? If the spec doesn't ban it, it allows it. Why shouldn't we do what Julian's DAV spec did? [0] If people are going to add stuff to the Atom namespace, then they're going to add stuff to the Atom namespace, irrespective of what the spec says. Your options are to live with that or enforce the building of machinery that will reject the markup of people who do it. To build that machinery you'll have to have an ability to proof-check the markup. To proof-check the markup you have to have to ensure its legal names and their combinations can be enumerated at design time - at a minimum. I am actually fine with going this route, but we should get rid of the syntactic constraints on link @rel if we're going to have a dictionary free-for-all in element names. What's the point, really. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg15255.html
Re: extensions -- Atom NS and unprefixed attributes
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Only, and this is not a joke, if you agree to add the text What this specification doesn't ban, it allows. Let's leave no room for doubt as to the spirit of interpretation. Future versions of this specification could add new elements and attributes to the Atom markup vocabulary. Software written to conform to this version of the specification will not be able to process such markup correctly and, in fact, will not be able to distinguish it from markup error. What error would that be? Robert Sayre
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Only, and this is not a joke, if you agree to add the text What this specification doesn't ban, it allows. Let's leave no room for doubt as to the spirit of interpretation. Future versions of this specification could add new elements and attributes to the Atom markup vocabulary. Software written to conform to this version of the specification will not be able to process such markup correctly and, in fact, will not be able to distinguish it from markup error. What error would that be? Too terse - I don't understand why you're asking this. But if you really think that we allow everything we don't ban, we should say that somewhere in the spec. cheers Bill
Re: extensions -- Atom NS and unprefixed attributes
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Too terse - I don't understand why you're asking this. But if you really think that we allow everything we don't ban, we should say that somewhere in the spec. hmm. I could write that Pace if you want, but maybe it would be more productive to explain why you find my interpretation psychotic. Maybe you could point to some spec text to back up your opinion. MarkN seems to think its only this or other IETF working groups that can extend the Atom namespace. I don't see anything in the spec about that. Robert Sayre
Re: extensions -- Atom NS and unprefixed attributes
On 5/15/05, Tim Bray [EMAIL PROTECTED] wrote: On May 10, 2005, at 9:14 PM, Robert Sayre wrote: entry fooBar=true title.../title evilExtension / ... /entry Legal? Which part of the spec rules it out? No part. Per http://www.atompub.org/2005/04/18/draft-ietf-atompub-format -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules for how to handle it, right? Yes, there are clear parsing rules. What's the benefit of allowing such markup? Robert Sayre P.S. -- I've created an atom:drm element. It resides in the W3C namespace and is RFC compliant. Its contents are subject to the provisions of the DMCA. For a small fee, you can read its specification.
Re: extensions -- Atom NS and unprefixed attributes
On May 10, 2005, at 9:14 PM, Robert Sayre wrote: entry fooBar=true title.../title evilExtension / ... /entry Legal? Which part of the spec rules it out? No part. Per http://www.atompub.org/2005/04/18/draft-ietf-atompub-format -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules for how to handle it, right? -Tim
Re: extensions -- Atom NS and unprefixed attributes
On May 15, 2005, at 9:43 PM, Robert Sayre wrote: evilExtension / Legal? Which part of the spec rules it out? No part. Per http://www.atompub.org/2005/04/18/draft-ietf-atompub-format -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules for how to handle it, right? Yes, there are clear parsing rules. What's the benefit of allowing such markup? The benefit the Web derived from HTML's implicit-but-universally-implemented MustIgnore rule; it introduced enough slack into the system that people could experiment without breaking things. Related resource: http://www.webratio.com/images/20050408Bosworth.pps More generally: ruling things out should be avoided unless (a) you're really sure they're harmful and (b) you think you can actually successfully enforce it. -Tim
Re: extensions -- Atom NS and unprefixed attributes
At 12:14 AM -0400 5/11/05, Robert Sayre wrote: On 5/9/05, Robert Sayre [EMAIL PROTECTED] wrote: I am fine with that. I am concerned that the current draft fails to differentiate between foreign markup and markup that requires IESG approval. I am going to try this again, because it's important. entry fooBar=true title.../title evilExtension / ... /entry Legal? Which part of the spec rules it out? Maybe I've read it too many times and I'm missing something. Common sense would seem to outlaw it, but that's not good enough. Hearing from as many people who feel that they understand the XML rules would be very good right about now... --Paul Hoffman, Director --Internet Mail Consortium
Re: extensions -- Atom NS and unprefixed attributes
Hello Paul, Many thanks for the citations below, this is extremely clear. Going back to the original question/pace that you gave a -1, would that change if in the text IETF Consensus was replaced with IESG Approval? Regards, Martin. At 10:56 05/05/11, Paul Hoffman wrote: At 4:15 PM +0900 5/10/05, Martin Duerst wrote: What's the difference between IETF consensus (for which you gave a -1) and it's up to the IESG (which seems what you think we should let happen)? From RFC 2434: IESG Approval - New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis). IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). --Paul Hoffman, Director --Internet Mail Consortium
Re: extensions -- Atom NS and unprefixed attributes
Hello Paul, What's the difference between IETF consensus (for which you gave a -1) and it's up to the IESG (which seems what you think we should let happen)? In my view, IETF consensus is another way of saying the IESG has the last word. If there is a better way to express this in the spec, then what would that be? Or would we say that because the atom namespace appears in an IETF spec, it's obvious that only the IETF (thus ultimately the IESG) can add stuff, but we don't have to say so? Regards, Martin. At 11:57 05/05/10, Paul Hoffman wrote: At 7:22 PM -0700 5/9/05, Tim Bray wrote: On May 9, 2005, at 6:52 PM, Robert Sayre wrote: I think we should be clearer that new elements in the Atom namespace and unprefixed attributes with parent elements in the Atom namespace can only be added by IETF consensus. Thoughts? I wonder if there's some standard IETF practice when you define a language as regards future change control? No. Nearly every protocol tries to go its own way. It's a mess. Generally -1. This spec defines what Atom 1.0 is, why try to micro-manage the future? -Tim Agree on the -1. At 10:34 PM -0400 5/9/05, Robert Sayre wrote: Fair enough. But can just anyone add stuff to the Atom namespace? If the IESG lets them, yes. We gotta trust the IESG after the WG shuts down. Fortunately, they have earned that trust over time. --Paul Hoffman, Director --Internet Mail Consortium
Re: extensions -- Atom NS and unprefixed attributes
On 5/9/05, Robert Sayre [EMAIL PROTECTED] wrote: I am fine with that. I am concerned that the current draft fails to differentiate between foreign markup and markup that requires IESG approval. I am going to try this again, because it's important. entry fooBar=true title.../title evilExtension / ... /entry Legal? Which part of the spec rules it out? Maybe I've read it too many times and I'm missing something. Common sense would seem to outlaw it, but that's not good enough. Robert Sayre
Re: extensions -- Atom NS and unprefixed attributes
On May 9, 2005, at 6:52 PM, Robert Sayre wrote: I think we should be clearer that new elements in the Atom namespace and unprefixed attributes with parent elements in the Atom namespace can only be added by IETF consensus. Thoughts? I wonder if there's some standard IETF practice when you define a language as regards future change control? Generally -1. This spec defines what Atom 1.0 is, why try to micro-manage the future? -Tim
Re: extensions -- Atom NS and unprefixed attributes
At 7:22 PM -0700 5/9/05, Tim Bray wrote: On May 9, 2005, at 6:52 PM, Robert Sayre wrote: I think we should be clearer that new elements in the Atom namespace and unprefixed attributes with parent elements in the Atom namespace can only be added by IETF consensus. Thoughts? I wonder if there's some standard IETF practice when you define a language as regards future change control? No. Nearly every protocol tries to go its own way. It's a mess. Generally -1. This spec defines what Atom 1.0 is, why try to micro-manage the future? -Tim Agree on the -1. At 10:34 PM -0400 5/9/05, Robert Sayre wrote: Fair enough. But can just anyone add stuff to the Atom namespace? If the IESG lets them, yes. We gotta trust the IESG after the WG shuts down. Fortunately, they have earned that trust over time. --Paul Hoffman, Director --Internet Mail Consortium
Re: extensions -- Atom NS and unprefixed attributes
On 5/9/05, Paul Hoffman [EMAIL PROTECTED] wrote: Fair enough. But can just anyone add stuff to the Atom namespace? If the IESG lets them, yes. We gotta trust the IESG after the WG shuts down. Fortunately, they have earned that trust over time. I am fine with that. I am concerned that the current draft fails to differentiate between foreign markup and markup that requires IESG approval. Robert Sayre
