Subject: extensions -- Atom NS and unprefixed attributes

From: Robert Sayre <[email-masked]>
Date: Mon, 9 May 2005 21:52:51 -0400

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?

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Mon, 09 May 2005 19:22:30 -0700

> 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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 9 May 2005 22:34:53 -0400

On 5/9/05, Tim Bray <[email-masked]> wrote:
 
> micro-manage the future? 

Fair enough. But can just anyone add stuff to the Atom namespace? 

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 May 2005 19:57:00 -0700

>language as regards future change control?

No. Nearly every protocol tries to go its own way. It's a mess.

>micro-manage the future? -Tim

Agree on the -1.

>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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 9 May 2005 23:01:12 -0400

> 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

---

From: Martin Duerst <[email-masked]>
Date: Tue, 10 May 2005 16:15:02 +0900

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.

 >We gotta trust the IESG after the WG shuts down. Fortunately, they have 
earned that trust over time.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 May 2005 18:56:20 -0700

>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

---

From: Robert Sayre <[email-masked]>
Date: Wed, 11 May 2005 00:14:57 -0400

> differentiate between "foreign markup" and "markup that requires IESG

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 May 2005 11:11:18 -0700

>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

---

From: Antone Roundy <[email-masked]>
Date: Wed, 11 May 2005 12:54:19 -0600

> rules" would be very good right about now...
I'm no expert on the actual rules, but here's my take:

* HTML has no concept of namespaces, so when people invent a new tag, 
they don't give it a unique prefix.  XML has namespaces, so when 
inventing new elements, common sense and past experience suggest 
putting them in a namespace under the control of the inventor.

* Atom is being defined by an RFC, in which the namespace is also 
specified.  Common sense suggests that without updating or obsoleting 
that RFC, new elements can't be added to that namespace unless the RFC 
itself defines a method for that being done.

* Common sense suggests that allowing third parties to insert elements 
into someone else's namespace makes little more sense than allowing 
third parties to change the definition of elements in someone else's 
namespace, which would clearly be ridiculous.

* If somebody publishes the above, who's going to do anything with 
evilExtension?  Nobody's going to know what it is, so it won't be 
processed, and won't do anything evil.  If it is evil, it won't get 
popular enough to be supported.  Even if it's not evil, I can't imagine 
it getting popular without a lot of people screaming about how it needs 
its own namespace, and thus it getting its own namespace.

* I presume the feed validator would choke on the above, right?

Question--do RFCs for any other XML formats explicitly state that 
something like the above is illegal?  If not, then I can't imagine we 
need to worry about it.

I'd think that if it needs to be stated explicitly that the above it 
illegal, unless putting things into others' namespaces was specifically 
intended to be allowed, the appropriate place for it would be in the 
namespace spec--not the specs for every XML format that uses namespaces.

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 11 May 2005 22:06:20 +0300

> putting them in a namespace under the control of the inventor.

Except it is pragmatic (in the sense of avoiding xmlns cruft) to put 
them in the NS of the language being extended. This is more likely 
happen if the original controller of the namespace neglects the 
language.

Case point: XHTML and WHAT WG.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Martin Duerst <[email-masked]>
Date: Wed, 11 May 2005 19:44:09 +0900

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.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 May 2005 18:21:53 -0700

>replaced with "IESG Approval"?

Yup.

--Paul Hoffman, Director

---

From: Tim Bray <[email-masked]>
Date: Sun, 15 May 2005 19:51:55 -0700

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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 May 2005 00:43:56 -0400

On 5/15/05, Tim Bray <[email-masked]> wrote:
> 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 RFCxxxx compliant. Its contents are subject to the
provisions of the DMCA. For a small fee, you can read its
specification.

---

From: Tim Bray <[email-masked]>
Date: Sun, 15 May 2005 22:11:27 -0700

> Yes, there are clear parsing rules. What's the benefit of allowing 

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

---

From: Sam Ruby <[email-masked]>
Date: Mon, 16 May 2005 06:11:32 -0400

> 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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 May 2005 09:27:26 -0400

> enough slack into the system that people could experiment without

Don't you think the Feed Validator should flag my example as invalid?

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Mon, 16 May 2005 09:59:01 -0700

> 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

---

From: Antone Roundy <[email-masked]>
Date: Mon, 16 May 2005 11:13:55 -0600

On Monday, May 16, 2005, at 10:59  AM, Tim Bray wrote:
> 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 
> 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."

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 May 2005 13:44:26 -0400

> MustUnderstand.

I don't think we are talking about the same issue.

>  That means that if the IETF wants to extend Atom, we 
> can do it as long as the extensions can be safely ignored. 

The problem is that anyone can extend the Atom namespace. 

> If you want 
> document namespace has to be changed. 

Right. I'm not looking to change that.

> I thought that the WG had 
> would prefer not to go back and repeat the discussion.

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.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Mon, 16 May 2005 18:50:51 +0100

On 16 May 2005, at 5:59 pm, Tim Bray wrote:

i)

> No.

ii)

> I actually thought that what we meant was what the spec said, and  
> 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

---

From: Tim Bray <[email-masked]>
Date: Mon, 16 May 2005 11:08:21 -0700

> 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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 May 2005 14:20:29 -0400

On 5/16/05, Tim Bray <[email-masked]> wrote:
> going to send Marshall Rose over to beat up anyone who tries?  

It will happen and we won't be able to stop it. 

> It's
> looking.  

Well, most documents probably use normative schemas for that. In fact,
our informative RNC rules it out. So, we'll either have to add
language to the spec or fix the RNC.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 16 May 2005 19:35:33 +0100

> It will happen and we won't be able to stop it. 

I have a question - what's the problem?

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 May 2005 20:52:11 +0200

Tim Bray wrote:
> 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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 May 2005 14:54:19 -0400

> 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>...
  <summary>My trip...</summary>
  <conten>My trip to the beach</conten>
  <links href="http://example.org">
</entry>

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Mon, 16 May 2005 15:30:59 -0400

>   <links href="http://example.org">

Does the same principle apply to attributes?

If a validator can't catch typos, what's left?

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 16 May 2005 20:32:48 +0100

Robert Sayre wrote:
> 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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 May 2005 15:42:26 -0400

> 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.
 
> 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

---

From: Tim Bray <[email-masked]>
Date: Mon, 16 May 2005 13:24:53 -0700

> If a validator can't catch typos, what's left?

It would be perfectly OK and expected for a validator to emit an 
"unrecognized element" diagnostic.

It would be really out of line for a desktop newsreader to refuse to 
display a feed because it has an unrecognized element, whether it's 
from the Atom namespace or not.  That's the behavior the current 
language supports.  I don't see how it gets in the way of validators. 
-Tim

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 16 May 2005 21:27:54 +0100

> namespace and be sure there would be no collision.

I still don't understand. Can't the IETF read their own specs?

>>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.

> 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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 May 2005 17:14:13 -0400

> 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.
 
> 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

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 16 May 2005 22:43:01 +0100

Robert Sayre wrote:
> 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]

> 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.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 May 2005 17:53:50 -0400

> 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]

> 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

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 16 May 2005 23:26:30 +0100

> what Julian's DAV spec did? [0]

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.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 May 2005 18:54:35 -0400

> 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

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 17 May 2005 00:16:54 +0100

> 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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 16 May 2005 21:02:52 -0400

> think that we allow everything we don't ban, we should say that

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

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 17 May 2005 09:37:14 +0100

> 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

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

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 May 2005 10:22:12 -0400

> > Maybe you could point to some spec text to back up your opinion.

My concern is about change control, not processing. We have an
elaborate system for controlling additions to the list of link
relations. Why aren't we more explicit with element names in the Atom
namespace?

I don't particularly care which strategy we settle on, but it's
important to be clear.

Do we have a situation similar to HTTP headers and methods, where you
can extend it as needed, but you had better 'coordinate' if you want
to make sure everyone interprets it the same way? That's fine. Or do
we have an IETF-administered registry?

If we do settle on the looser approach for elements, I suggest we drop
the link registry and go with the space-separated lists allowed by
HTML.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Tue, 17 May 2005 08:47:31 -0600

> we have an IETF-administered registry?
XML namespaces create a middle road between the two--anyone can add 
elements to an XML document without fear of naming collisions because 
XML has a built-in coordination method.  What possible advantage would 
there be to allowing just anyone to add elements to Atom's namespace, 
or any other namespace, for that matter?  I can't think of any.  In my 
opinion, alteration of a namespace by anyone other than the entity that 
created it, or someone authorized by its creator, would completely 
violate the nature of namespaces.  I wouldn't think it would be 
necessary to spell that out explicitly, but since obviously not 
everyone agrees, we may as well do so.

So I'd say we have an IETF-administered registry.

---

From: Graham <[email-masked]>
Date: Tue, 17 May 2005 16:57:00 +0100

On 17 May 2005, at 3:47 pm, Antone Roundy wrote:

> elements to an XML document without fear of naming collisions  
> because XML has a built-in coordination method.  What possible  
> advantage would there be to allowing just anyone to add elements to  
> Atom's namespace, or any other namespace, for that matter?  I can't  
> think of any.  In my opinion, alteration of a namespace by anyone  
> other than the entity that created it, or someone authorized by its  
> creator, would completely violate the nature of namespaces.  I  
> wouldn't think it would be necessary to spell that out explicitly,  
> but since obviously not everyone agrees, we may as well do so.
>

Put me in the "Only those elements defined in IETF RFCs may use the  
Atom namespace" column.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Wed, 18 May 2005 02:16:55 +1000

> Put me in the "Only those elements defined in IETF RFCs may use the

+1

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 17 May 2005 19:31:16 +0200

>>Put me in the "Only those elements defined in IETF RFCs may use the
+1 as well

-- 
Thomas Broyer

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 19 May 2005 00:17:38 +0300

On May 17, 2005, at 17:47, Antone Roundy wrote:

> What possible advantage would there be to allowing just anyone to add 
> elements to Atom's namespace, or any other namespace, for that matter? 
>  I can't think of any.

If you add to an existing namespace, you don't need to add confusing 
namespace declarations.

> In my opinion, alteration of a namespace by anyone other than the 
> entity that created it, or someone authorized by its creator, would 
> completely violate the nature of namespaces.

Sure. But it happens for practical reasons.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Antone Roundy <[email-masked]>
Date: Wed, 18 May 2005 16:02:50 -0600

On Wednesday, May 18, 2005, at 03:17  PM, Henri Sivonen wrote:
>> elements to Atom's namespace, or any other namespace, for that 
>> matter?  I can't think of any.
>
Sheesh.  If you can't be bothered to add a "confusing" namespace 
declaration, then you should be using plain text instead of XML.