Subject: Low-hanging fruit: compulsory namespaces

From: Tim Bray <[email-masked]>
Date: Tue, 13 Jul 2004 14:56:00 -0700

I suggest that we have good enough consensus to remove the paragraph in 
draft-format-00 in section 2. beginning "All elements and attributes in 
an Atom document MUST be namespace-qualified".  Because lots of 
attributes aren't, and when it was pointed out that this would forbid 
encapsulating RSS 2.0 and Docbook, nobody pushed back and said "it's OK 
to forbid that".  -Tim

---

From: Antone Roundy <[email-masked]>
Date: Tue, 13 Jul 2004 16:32:35 -0600

On Tuesday, July 13, 2004, at 03:56  PM, Tim Bray wrote:
> I suggest that we have good enough consensus to remove the paragraph 
> in draft-format-00 in section 2. beginning "All elements and 
> attributes in an Atom document MUST be namespace-qualified".  Because 
> lots of attributes aren't, and when it was pointed out that this would 
> forbid encapsulating RSS 2.0 and Docbook, nobody pushed back and said 
> "it's OK to forbid that".  -Tim
>
I think I missed something--where would one put RSS 2.0 into an Atom 
feed?  In a content construct?  As inline XML?  How would that be done 
without creating namespace conflicts, assuming the Atom document has 
Atom's namespace as the default namespace?  Is this the correct answer 
to my own question?

<feed xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-00">
	<entry>
		<atom:content type="application/rss+xml" xmlns="" 
xmlns:atom="http://purl.org/atom/ns#draft-ietf-atompub-format-00">
			<!-- RSS 2.0 goes here -->
		</atom:content>
	</entry>
</feed>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Jul 2004 15:44:25 -0700

+1.

Do we want to replace this with something along the lines of "children 
of atom:feed and atom:entry must be namespace-qualified?"

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Tue, 13 Jul 2004 17:02:50 -0600

I would argue that all elements (at least) need to be namespace qualified, 
even if means using xmlns="" to undeclare a namespace for things like 
embedded RSS.  +1 to not requiring all attributes to be namespace 
qualified except for the obvious global attributes (e.g. mustUnderstand)

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

Tim Bray <[email-masked]> 
Sent by: [email-masked]
07/13/2004 02:56 PM

To
Atomlist Syntax <[email-masked]>
cc

Subject
Low-hanging fruit: compulsory namespaces

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 14 Jul 2004 00:18:04 +0100

Tim Bray wrote:

> an Atom document MUST be namespace-qualified".  

Well, hang on there. Take the entire paragraph:

[[[
All elements and attributes in an Atom document MUST be 
namespace-qualified.  Note that this requirement does not preclude 
the use of a default namespace.
]]]

Although I confess I don't know why the last sentence needs to call 
out default namespaces at all, without specifying namespace 
qualification while specifying that default namespace are ok, there 
is room for bleed due to default namespaces. Perhaps if you want to 
strike it, you should add words around xmlns="". Sam mentioned 
xmlns="" recently and it's the only workable means I know of to mix 
plain and namespaced XML. It seems problematic enough that we should 
spec it in:

"All elements in an Atom document MUST be namespace-qualified. Where 
an XML element does not belong to a namespace it MUST be qualified 
by an xmlns="" declaration.  An attribute belonging to an element 
MAY be namespace qualified by that element's namespace. Any 
attribute foreign to an element MUST be namespace-qualified with a 
namespace other than the element's. @@@insert conclusion of QNames 
in content permathread here@@@"

Aside: a side effect of namespaces is that names at different level 
in the document are conflated to one name. We seem to have a number 
of these : title, link, modified, contributor, id, author, 
copyright. Care needs to be taken in the drafts that each of these 
are actually specified once.

cheers
Bill

---

From: Norman Walsh <[email-masked]>
Date: Tue, 13 Jul 2004 19:23:47 -0400

/ Mark Nottingham <[email-masked]> was heard to say:
| +1.
|
| Do we want to replace this with something along the lines of "children
| of atom:feed and atom:entry must be namespace-qualified?"

That seems reasonable to me.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Many who find the day too long, think
http://nwalsh.com/            | life too short.--Charles Caleb Colton

---

From: Tim Bray <[email-masked]>
Date: Tue, 13 Jul 2004 16:24:46 -0700

> of atom:feed and atom:entry must be namespace-qualified?"

Sounds good, but of course it hasn't been discussed so we might be 
missing some obvious gotcha.  I'd put it in, on a trial-balloon basis. 
-Tim

---

From: Tim Bray <[email-masked]>
Date: Tue, 13 Jul 2004 16:53:25 -0700

On Jul 13, 2004, at 4:18 PM, Bill de hÓra wrote:

>  Perhaps if you want to strike it, you should add words around 
> xmlns="". Sam mentioned xmlns="" recently and it's the only workable 
> means I know of to mix plain and namespaced XML. It seems problematic 
> enough that we should spec it in:
>
> an XML element does not belong to a namespace it MUST be qualified by 
> an xmlns="" declaration.  An attribute belonging to an element MAY be 
> namespace qualified by that element's namespace. Any attribute foreign 
> to an element MUST be namespace-qualified with a namespace other than 
> the element's. @@@insert conclusion of QNames in content permathread 
> here@@@"

No.  XML elements and attributes are either in a namespace or they're 
not.  We should not get into micromanaging the various syntactic tricks 
you could use to accomplish this.  E.g. the following two are both 
perfectly OK and effectively identical:

<!-- assume atom: prefix is declared -->
<!-- assume no default namespace -->
<atom:entry>
  <atom:issued>...
  .. other <atom:xxx> tags
  ..
  <atom:content type="application/rss2+xml">
   <item><title>A chunk of RSS</title></item>
  </atom:content>
</atom:entry>

==============================

<entry xmlns=".. atom's namespace URI.."
  <issued>...
    ... other atom tags
  <content type="application/rss2+xml">
   <item xmlns=""><title></title></item>
  </content>

  -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 14 Jul 2004 02:21:06 +0100

Tim Bray wrote:

> <snip examples/>

Sorry, the two examples are not identical (don't know what you mean 
by 'effectively'). The second will survive continuous processing, 
the first will not. Pump the first through enough downstream 
processors and there's a chance the prefixes will get dropped 
(there's nothing in the namespaces spec to prevent it). This stuff 
is error and bork prone in much the same way encodings are, For 
plain markup carried in Atom we should really be saying something 
about setting the default namespace to the empty string.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Tue, 13 Jul 2004 22:08:20 -0400

> of atom:feed and atom:entry must be namespace-qualified?"

Add atom:author and atom:contributor.

- Sam Ruby

---

From: Norman Walsh <[email-masked]>
Date: Wed, 14 Jul 2004 06:58:36 -0400

/ Bill de hÓra <[email-masked]> was heard to say:
| Tim Bray wrote:
[...]
|> No.  XML elements and attributes are either in a namespace or
|> they're not.  We should not get into micromanaging the various
|> syntactic tricks you could use to accomplish this.  E.g. the
|> following two are both perfectly OK and effectively identical:
|> <snip examples/>
|
| Sorry, the two examples are not identical (don't know what you mean by
| 'effectively').

No. Sorry. Tim is right. Modulo the prefixes used, those two examples
*are the same*.

| The second will survive continuous processing, the first will not.
| Pump the first through enough downstream processors and there's a
| chance the prefixes will get dropped (there's nothing in the
| namespaces spec to prevent it).

Yes, the prefixes might get dropped, but if they do, then the resulting
document absolutely must come out like this:

<entry xmlns="atom namespace">
  <issued>...
  .. other <xxx> tags
  ..
  <content type="application/rss2+xml">
   <item xmlns=""><title>A chunk of RSS</title></item>
  </content>
</entry>

This is just a third way to write *the same* document.

Any other result is a bug in the processor.

| This stuff is error and bork prone
| in much the same way encodings are, For plain markup carried in Atom
| we should really be saying something about setting the default
| namespace to the empty string.

I disagree, but I don't object to saying something as long as what we
say is true.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | He who fails to become a giant need not
http://nwalsh.com/            | remain content with being a
                              | dwarf.--Ernest Bramah

---

From: Tim Bray <[email-masked]>
Date: Wed, 14 Jul 2004 06:53:55 -0700

On Jul 13, 2004, at 6:21 PM, Bill de hÓra wrote:

> Sorry, the two examples are not identical (don't know what you mean by 
> 'effectively'). The second will survive continuous processing, the 
> first will not. Pump the first through enough downstream processors 
> and there's a chance the prefixes will get dropped (there's nothing in 
> the namespaces spec to prevent it). This stuff is error and bork prone 
> in much the same way encodings are, For plain markup carried in Atom 
> we should really be saying something about setting the default 
> namespace to the empty string.

I went back and reviewed the examples, and I totally disagree.  They 
really are the same, and any chain of processing software that makes 
them come out different is severely buggy, and I don't think bugginess 
at that level is prevalent in widely-used XML-processing tools.

I don't think we should be micromanaging how people do their namespace 
mappings, just like I don't think we should be telling people to prefer 
either of these two over the other

<title>Pat &amp; Mike</title>      <title><![CDATA[Pat & Mike]]></title>

-Tim

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 14 Jul 2004 15:21:18 +0100

> at that level is prevalent in widely-used XML-processing tools.

Ok, I won't dispute that re deployed processor behaviour. But I went 
back and reread the 1.1 Namespaces spec today and I didn't see where 
behaving the way you and Norm say they should not is considered a 
processing error. Seriously, did I miss it?

cheers
Bill

---

From: Norman Walsh <[email-masked]>
Date: Wed, 14 Jul 2004 11:38:32 -0400

/ Bill de hÓra <[email-masked]> was heard to say:
| Tim Bray wrote:
|
|> I went back and reviewed the examples, and I totally disagree.  They
|> really are the same, and any chain of processing software that makes
|> them come out different is severely buggy, and I don't think
|> bugginess at that level is prevalent in widely-used XML-processing
|> tools.
|
| Ok, I won't dispute that re deployed processor behaviour. But I went
| back and reread the 1.1 Namespaces spec today and I didn't see where
| behaving the way you and Norm say they should not is considered a
| processing error. Seriously, did I miss it?

I'm not actually sure what you're asking. Given this document

  <atom:feed xmlns:atom="http://example.org/atom">
    <atom:content mode="xml">
      <no-ns>Non-namespaced element</no-ns>
    </atom:content>
  </atom:feed>

What transformation do you think should be valid that you believe
I think is not valid?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | In great affairs men show themselves as
http://nwalsh.com/            | they wish to be seen, in small things
                              | they show themselves as they are.--
                              | Chamfort

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 14 Jul 2004 11:48:50 -0400

If I may, another "earlier IETF work" pointer that discusses XML namespaces:

ftp://ftp.rfc-editor.org/in-notes/rfc3688.txt

This "best current practice" RFC talks about URIs used in IETF standards to
identify XML namespaces.

-Scott-

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 14 Jul 2004 16:59:28 +0100

> What transformation do you think should be valid that you believe

I'm not sure what you mean. To me, this is not about what I think 
about valid transformations in and out of default namespaces. It's 
about whether those transformations are specified.

Honestly, in the absence of being to point at normative text and say 
  'clown, your processing is broken', I would expect an utterance 
along the lines of 'inside Atom, you SHOULD qualify your 
non-namespace markup with xmlns=""' to aid robustness and increase 
happiness all round. I'm backing down from MUST since you and Tim 
have pointed out this is buggy behaviour for tools, my mistake. But 
there are plenty of people rolling their own with namespaces out 
there. Saying SHOULD around xmlns="" qualification is not specifying 
bad practice, is not constraining to those who practice well, is not 
subsetting existing 'legal' processing. But it is a useful thing to 
say and I don't believe for a second it's micro-management.

Does that make sense?

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Wed, 14 Jul 2004 09:49:39 -0700

On Jul 14, 2004, at 8:59 AM, Bill de hÓra wrote:

> I would expect an utterance along the lines of 'inside Atom, you 
> SHOULD qualify your non-namespace markup with xmlns=""' to aid 
> robustness and increase happiness all round.

Hmm... maybe I'm unusually lucky but I just haven't been bitten by 
things going wrong in this space, and I think I use a reasonably 
vanilla selection of XML tools.  So I'm still uncomfortable with 
putting it in an RFC.  On the other hand, if Bill is one of many who 
get bitten by this kind of thing and would like a good-practice note, 
speak on up. -Tim

---

From: James M Snell <[email-masked]>
Date: Wed, 14 Jul 2004 11:40:58 -0600

> get bitten by this kind of thing and would like a good-practice note, 

Where this really becomes an issue is situations where atom:feed MAY be 
placed into other XML documents, for example, a SOAP envelope.  Imagine, 
for instance, odd as it may be, an RPC style Web service method that 
returns an atom:feed.  Apache Axis (and I believe a few other Web service 
engines) have the tendency to serialize the elements representing the 
operation using the default namspace, so what you get is something that 
looks like:

<s:Envelope xmlns:s="...">
  <s:Body>
    <getFeedResponse xmlns="...">
      <atom:feed>...</atom:feed>
    </getFeedResponse>
  </s:Body>
</s:Envelope>

Now, imagine that the atom feed was generated by some other piece of 
application code that simply handed it off as a DOM document or XML string 
or whatever to the web service engine.  The engine has no way of knowing 
whether or not the XML contained within it has non-namespace qualified 
elements, so you could end up with something like:

<s:Envelope xmlns:s="...">
  <s:Body>
    <getFeedResponse xmlns="...">
      <atom:feed>
        <foo />
      </atom:feed>
    </getFeedResponse>
  </s:Body>
</s:Envelope>

Where suddenly the <foo /> element, which should not be in any namespace 
at all, is now suddenly placed within the same namespace as the 
<getFeedResponse /> element.

The question becomes: whose problem is this?  Is it the Web services 
engines problem?  That is, should the engine be aware that it may be 
handed XML that contains non-qualified elements and do things to ensure 
that the embedded XML will still be valid (e.g. not serialize any of the 
top level elements using the default namespace as in option 1 below).  Or 
is it the atom:feed generators problem?  That is, should the code 
generating the atom xml be aware that what it is generating may be 
contained in another bit of XML that may itself define elements in the 
default namespace and do things to protect it's non-qualified elements as 
in option 2 below.

Option 1
<s:Envelope xmlns:s="...">
  <s:Body>
    <n:getFeedResponse xmlns:n="...">
      <atom:feed>
        <foo />
      </atom:feed>
    </n:getFeedResponse>
  </s:Body>
</s:Envelope>

Option 2
<s:Envelope xmlns:s="...">
  <s:Body>
    <getFeedResponse xmlns="...">
      <atom:feed>
        <foo xmlns="" />
      </atom:feed>
    </getFeedResponse>
  </s:Body>
</s:Envelope>

I would argue that both approaches are valid.  If you expect your XML to 
be embedded in other XML and your XML contains non-qualified elements, you 
SHOULD use xmlns="".  If you expect your XML to contain XML that may have 
non-qualified elements, you should not use the default namespace for any 
of your container elements.  This is reflected in Option 3

Option 3
<s:Envelope xmlns:s="...">
  <s:Body>
    <n:getFeedResponse xmlns:n="...">
      <atom:feed>
        <foo xmlns="" />
      </atom:feed>
    </n:getFeedResponse>
  </s:Body>
</s:Envelope>

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Jul 2004 10:48:20 -0700

+1 - this is a best practice

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 14 Jul 2004 22:41:20 +0100

Tim Bray wrote:

> things going wrong in this space, and I think I use a reasonably vanilla 
> selection of XML tools.  So I'm still uncomfortable with putting it in 
> an RFC.  On the other hand, if Bill is one of many who get bitten by 
> this kind of thing and would like a good-practice note, speak on up. -Tim

Thanks, but I wasn't looking for a BP. I do accept what you've said 
about buggy tools, but what the tools are doing vis-a-vis the right 
thing is not spec'd as far as I can tell (I checked as best I 
could). This goes beyond a tooling or best practice issue, and 
points to architecture - in an internet where everyone and their dog 
has an XML envelope and is careful to keep processing of said 
envelope and body orthogonal, default namespaced XML and plain XML 
don't mesh well. Then again, we can't even get wf XML to be the 
general case for feeds so maybe I'm on crack asking for something 
like this.

Thanks to the XML enveloping bonaza, assuming what's in front of 
your eyes right now is the whole XML document and not a child node 
is a fallacy in the spirit of Deutsch - you absolutely have to 
expect your markup to get embedded. Thusly, Jame's Options 1 *and* 2 
cease to be valid - Option 3 is what remains as the only robust 
approach (as in being strict in what you emit). My answer to Jame's 
question, "whose problem is this?" is twofold;  1) it's no-one's 
problem because it's too easy for anyone to say it's not my problem. 
2) it becomes a non-problem when people take care to qualify any 
plain XML they expect will get onto to the web inside xmlns="".

My position is still that I would like to see words in the format 
around xmlns="" - respectfully, it a no-brainer to SHOULD it. Other 
than that, I think I'm done talking it up :)

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Wed, 14 Jul 2004 16:23:39 -0600

> > things going wrong in this space, and I think I use a reasonably 
vanilla 

> than that, I think I'm done talking it up :)

+1 on this.  While my options 1 & 2 are, strictly speaking, valid 
approaches, they are not robust.  Assuming that Atom feeds MAY be embedded 
in other XML documents, child elements that do not belong to a namespace 
SHOULD include the xmlns="" null namespace declaration.

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 14 Jul 2004 15:59:21 -0700 (PDT)

> than that, I think I'm done talking it up :)

-1. 

I agree with Tim. I haven't seen this behavior in any
of the various XML tools I've used in the wild. It
seems this would basically be putting potentially
confusing text about namespaces in the text due to one
or two buggy implementations of XML tools or some bad
code that someone once saw on the Web. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 15 Jul 2004 00:33:26 +0100

Dare Obasanjo wrote:

> of the various XML tools I've used in the wild. 

It's already been pointed out that this is not a tools matter.

> It
> confusing text about namespaces in the text 

Please explain what you find confusing.

cheers
Bill

---

From: steve jenson <[email-masked]>
Date: Wed, 14 Jul 2004 17:05:20 -0700

> get bitten by this kind of thing and would like a good-practice note, 

Blogger feeds won't wrap your content in a <div 
xmlns="http://www.w3.org/1999/xhtml"> if your fragment is well formed. 
Sometimes this means that you'll end up with html tags in the atom 
namespace. I didn't notice this was a problem until users of 
Mozilla-based newsreaders pointed it out. A note like this would have 
persuaded me to unset the default namespace before the problem arose.

Steve

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Jul 2004 17:04:11 -0700

On Jul 14, 2004, at 2:41 PM, Bill de hÓra wrote:

> thing is not spec'd as far as I can tell (I checked as best I could). 
> This goes beyond a tooling or best practice issue, and points to 
> architecture - in an internet where everyone and their dog has an XML 
> envelope and is careful to keep processing of said envelope and body 
> orthogonal, default namespaced XML and plain XML don't mesh well. Then 
> again, we can't even get wf XML to be the general case for feeds so 
> maybe I'm on crack asking for something like this.
>
> Thanks to the XML enveloping bonaza, assuming what's in front of your 
> eyes right now is the whole XML document and not a child node is a 
> fallacy in the spirit of Deutsch - you absolutely have to expect your 
> markup to get embedded. Thusly, Jame's Options 1 *and* 2 cease to be 
> valid - Option 3 is what remains as the only robust approach (as in 
> being strict in what you emit). My answer to Jame's question, "whose 
> problem is this?" is twofold;  1) it's no-one's problem because it's 
> too easy for anyone to say it's not my problem. 2) it becomes a 
> non-problem when people take care to qualify any plain XML they expect 
> will get onto to the web inside xmlns="".
>

Hi Bill,

I would very much like to see this kind of language in a "Best 
Practices" appendix or a Primer, but would object to making it 
normative with a SHOULD. It's advice about the use of an underlying 
specification -- Namespace in XML -- not specific to Atom. There may 
not be RFC2119 language specifically addressing this situation in the 
underlying specifications, but the implications of namespace defaulting 
are clear upon a careful reading of the appropriate specs; we just need 
to emphasise that for implementers and users, not place a normative 
requirement on them.

Cheers,

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 14 Jul 2004 17:17:09 -0700 (PDT)

> Please explain what you find confusing.

I don't find anything confusing. Many of my users in
my dayjob (users of XML on Microsoft platforms) are
confused by XML namespaces and it is all black magic
to them why changing an attribute {default namespace
decl) can make their previously working XPath
expressions fail. 

I don't think putting some 'best practice' for broken
tools [which is what I saw in the examples James
showed] won't lead to confusion to XML novices who are
working with Atom on how XML namespaces are used. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 20:26:06 -0400

> persuaded me to unset the default namespace before the problem arose.

Ouch.  I'll go fix the feedvalidator to check fot this.

- Sam Ruby

---

From: steve jenson <[email-masked]>
Date: Wed, 14 Jul 2004 17:29:43 -0700

On Jul 14, 2004, at 5:26 PM, Sam Ruby wrote:

>> xmlns="http://www.w3.org/1999/xhtml"> if your fragment is well 
>> formed. Sometimes this means that you'll end up with html tags in the 
>> atom namespace. I didn't notice this was a problem until users of 

That would have persuaded me, too!

Thanks,
Steve

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 14 Jul 2004 17:42:13 -0700 (PDT)

> persuaded me to unset the default namespace before

This implies that Blogger is not using XML tools to
generate their feeds. No XML tools I've come across
would make such mistakes unless they are extremely
buggy. I think adding this text to the normative spec
is akin to adding stuff like 'best practices for
parsing XML with regexes' in the spec. 

Putting it in a primer or an Atom tutorial is OK but I
don't think it should be in the spec. Workarounds for
buggy products and tutorials for basic XML
fundamentals shouldn't clutter the spec especially
when it may give the readers the implication that
there is more significance to this text than there
actually is. 

=====

---

From: steve jenson <[email-masked]>
Date: Wed, 14 Jul 2004 17:44:32 -0700

> parsing XML with regexes' in the spec.

I'm using the DOM provided with Java 1.4.2. It does have
plenty of bugs. I guess this is another one.

-steve

---

From: James M Snell <[email-masked]>
Date: Wed, 14 Jul 2004 22:25:14 -0600

> there is more significance to this text than there

I'm good with this as long as it's at least mentioned *somewhere*... A 
primer for atom implementors, for instance.  Something that could go 
through and delineate various issues that represent best practice concerns 
vs. stuff that should codified in the spec. 

Perhaps we should create a "BestPractices" page in the wiki where we can 
start to collect these types of issues to keep track of them until a 
primer can be written?

> My dungeon will have its own qualified medical staff complete with 
> bodyguards. That way if a prisoner becomes sick and his cellmate 
> tells the guard it's an emergency, the guard will fetch a trauma 
> team instead of opening up the cell for a look.
> 
> 
> 

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 15 Jul 2004 10:38:32 +0100

> parsing XML with regexes' in the spec. 

Can you show me the spec text that indicates this is a bug? I 
couldn't find it.

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jul 2004 12:01:51 +0200

Bill de hÓra wrote:
> Can you show me the spec text that indicates this is a bug? I couldn't 
> find it.

Bill,

if the DOM you're using supports DOM level 2, and is working in 
namespace-aware mode, no legal DOM method call (such as 
importNode/addChild) may mess with namespace names of existing nodes. If 
this occurs, this is a severe bug.

On the other hand, maybe it's not the DOM implementation itself, but 
broken DOM serialization code that's causing the problem you're seeing? 
Back a few years ago, when I tried to use Xerces' (version 1) XML 
serializer (which is the predecessor of what's in jdk 1.4 AFAIK), I 
eventually had to give up and write my own, because it didn't work well 
with namespaces. I'm not sure how much the situation has improved since 
(if it doesn't, we've got Tim here to make people aware of it :-).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 15 Jul 2004 11:59:53 +0100

> this occurs, this is a severe bug.

Julian,

Thanks, that's good to hear; I'll dig out the relevant text. My 
suspicion is that the reason these things don't work to well with 
namespaces is because namespaces doesn't say anything (?) about 
constrining "pollution" via default scoping rules, it just says what 
default scoping rules are the case. This is the issue - the right 
thing by regular and namespaced markup is consistently someone's 
else's problem; one is left to infer it instead of having an 
explicitly stated constraint. [this is not a "pity the children" 
argument it's a "specification by interpretation is an oxymoron" 
argument.]

As for a BP/Primer. I wouldn't bet on a primer or rely on such a 
thing to get the right thing done - if Atom needs a Primer, we've 
failed as a WG in my opinion. I guess we'd better all use DOM L2/3 
in the meantime!

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jul 2004 13:33:36 +0200

Bill de hÓra wrote:

>> importNode/addChild) may mess with namespace names of existing nodes. 
>> If this occurs, this is a severe bug.
> 
> 
> Julian,
> 
> default scoping rules are the case. This is the issue - the right thing 
> by regular and namespaced markup is consistently someone's else's 
> problem; one is left to infer it instead of having an explicitly stated 
> constraint. [this is not a "pity the children" argument it's a 
> "specification by interpretation is an oxymoron" argument.]

I think it's up to DOM to specify what adding namespaced childs (without 
explicit prefix) means. And I'd be *very* surprised if it would allow an 
implementation to change the namespace name because of that.

As far as I can tell, the issue is with serialization, not DOM 
construction, and thus it's (unfortunately) out of the scope of DOM level 2.

> As for a BP/Primer. I wouldn't bet on a primer or rely on such a thing 
> to get the right thing done - if Atom needs a Primer, we've failed as a 
> WG in my opinion. I guess we'd better all use DOM L2/3 in the meantime!

Best regards, Julian

---

From: Norman Walsh <[email-masked]>
Date: Fri, 16 Jul 2004 09:01:54 -0400

/ Bill de hÓra <[email-masked]> was heard to say:
| Dare Obasanjo wrote:
|
|> This implies that Blogger is not using XML tools to
|> generate their feeds. No XML tools I've come across
|> would make such mistakes unless they are extremely
|> buggy. I think adding this text to the normative spec
|> is akin to adding stuff like 'best practices for
|> parsing XML with regexes' in the spec.
|
| Can you show me the spec text that indicates this is a bug? I couldn't
| find it.

I can't help answer that question until I understand the antecedent of
"this" in that sentence. I tried[1] to get an answer to that question
before, but we failed[2] to communicate. I'll try again momentarily.

                                        Be seeing you,
                                          norm

[1] http://www.imc.org/atom-syntax/mail-archive/msg06975.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg06981.html

-- 
Norman Walsh <[email-masked]> | Almost every man wastes part of his
http://nwalsh.com/            | life in attempts to display qualities
                              | which he does not possess, and to gain
                              | applause which he cannot keep.--Dr.
                              | Johnson

---

From: Norman Walsh <[email-masked]>
Date: Fri, 16 Jul 2004 08:57:39 -0400

/ steve jenson <[email-masked]> was heard to say:
| I'm using the DOM provided with Java 1.4.2. It does have
| plenty of bugs. I guess this is another one.

Maybe I'm just being sensitive :-), but I expect that's got more
to do with DOM's support for namespaces than a bug in 1.4.2.
It also depends on which DOM interfaces you're using.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Extinction, n. The raw material out of
http://nwalsh.com/            | which theology created the future
                              | state.--Ambrose Bierce

---

From: Norman Walsh <[email-masked]>
Date: Fri, 16 Jul 2004 09:20:38 -0400

/ Bill de hÓra <[email-masked]> was heard to say:
| Norman Walsh wrote:
|
|> I'm not actually sure what you're asking. Given this document
|>   <atom:feed xmlns:atom="http://example.org/atom">
|>     <atom:content mode="xml">
|>       <no-ns>Non-namespaced element</no-ns>
|>     </atom:content>
|>   </atom:feed>
|> What transformation do you think should be valid that you believe
|> I think is not valid?
|
| I'm not sure what you mean. To me, this is not about what I think
| about valid transformations in and out of default namespaces. It's
| about whether those transformations are specified.

This is where we're failing to communicate. Let's take a closer look
at my example:

1   <atom:feed xmlns:atom="http://example.org/atom">
2     <atom:content mode="xml">
3       <no-ns>Non-namespaced element</no-ns>
4     </atom:content>
5   </atom:feed>

On line 1, the atom:feed element is in the namespace
"http://example.org/atom". I expect that's uncontroversial. It follows
directly from Section 2 of the NS Rec.

Similarly, on Line 2, the atom:content element is in the namespace
"http://example.org/atom". This follows from Section 5.1 of the NS Rec.

Line 3 is probably the source of contention, but I may be wrong. I
contend that the element "no-ns" is not in any namespace. I base this
conclusion on the following statements from the NS Rec.

  1. From Section 5.2: "A default namespace is considered to apply to
     the element where it is declared (if that element has no
     namespace prefix), and to all elements with no prefix within the
     content of that element."

     There is no declaration for the default namespace in this
     document, so this rule does not apply.

  2. From Section 5.1: "The namespace declaration is considered to
     apply to the element where it is specified and to all elements
     within the content of that element, unless overridden by another
     namespace declaration with the same NSAttName part"

     Now, this says that the atom: prefix is in scope for the
     no-ns element, but

  3. From Section 3: "The Prefix provides the namespace prefix part of
     the qualified name, and must be associated with a namespace URI
     reference in a namespace declaration."

     The element "no-ns" does not have a prefix so it is not
     in that namespace.

If the no-ns element isn't in the namespace associated with the atom:
prefix (because it doesn't have a qualified name with the atom:
prefix), and if there's no default namespace declared, the element
no-ns is in no namespace.

I grant you that the NS Rec doesn't actually say that the default
default for the default namespace is "not in any namespace", but I
don't believe that any other interpretation is justified.

| Honestly, in the absence of being to point at normative text and say
| 'clown, your processing is broken',

If you agree with my description above, then "no-ns" is not in any
namespace. Any tool that loses that information and allows it to
"leak" into another namespace is broken.

If you don't agree with my description above, please tell me how you
interpret the spec differently.

                                        Be seeing you,
                                          norm

[1] http://www.w3.org/TR/REC-xml-names/

-- 
Norman Walsh <[email-masked]> | Life always comes to a bad end.--Marcel
http://nwalsh.com/            | AymÃ©

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 16 Jul 2004 14:47:34 +0100

> This is where we're failing to communicate. Let's take a closer look

   0   <outer xmlns="...">
> 3       <no-ns>Non-namespaced element</no-ns>
   6   </outer>

> interpret the spec differently.

See above.

cheers
Bill

---

From: Norman Walsh <[email-masked]>
Date: Fri, 16 Jul 2004 16:24:18 -0400

/ Bill de hÓra <[email-masked]> was heard to say:
| Norman Walsh wrote:
|
|> This is where we're failing to communicate. Let's take a closer look
|> at my example:
|
|    0   <outer xmlns="...">
|> 1   <atom:feed xmlns:atom="http://example.org/atom">
|> 2     <atom:content mode="xml">
|> 3       <no-ns>Non-namespaced element</no-ns>
|> 4     </atom:content>
|> 5   </atom:feed>
|    6   </outer>
|
|> If you don't agree with my description above, please tell me how you
|> interpret the spec differently.
|
| See above.

I'm still confused. That's a different document. Are you asking me
what that document means, or are you saying that you have a tool that
produced that document from mine?

If you have an XML tool and you took my document (lines 1-5) and
dropped it into your document (between the "outer" tags) and the
result you got back is shown above, your tool is broken. Your tool was
required, by the specs, as I demonstrated in the original message, to
produce:

 0   <outer xmlns="...">
 1   <atom:feed xmlns:atom="http://example.org/atom">
 2     <atom:content mode="xml">
 3       <no-ns xmlns="">Non-namespaced element</no-ns>
 4     </atom:content>
 5   </atom:feed>
 6   </outer>

Anything else is a bug.

Does that help?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | When we are tired, we are attacked by
http://nwalsh.com/            | ideas we conquered long ago.-- Nietzsche

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 16 Jul 2004 21:58:38 +0100

Norman Walsh wrote:

> I'm still confused. That's a different document. 

I said elsewhere that we should expect that our XML will get 
embedded. I claim that your rule 1. must *always* apply - saying it 
doesn't apply is seems only useful for the local case and is not robust.

> Are you asking me

Neither. I'm  saying I've seen this kind of markup in the wild in 
the same way I've seen application libraries emit malformed XML in 
the wild. It tends to gravitate around "envelope-oriented" markup. I 
have my suspicions as to why but don't care to generalize.

> required, [...]

How is it required? I do not see an entailment from your 3 point 
interpretation of namespaces to this bug. I keep going back to them 
and reading them, but it just doesn't follow. And please stop saying 
"your tool". I did not raise tools as being the issue here.

> Does that help?

I guess not. People keep telling me it's a bug, but not why it's a 
bug. In any case I've already signed up "it's a bug" view. But I 
will call it a consensus view only. My point/question has always 
been whether this is something that is *specified* somewhere. 
However many days into this thread, I'm still not seeing that 
specification.

We're way off topic by now. I was looking for a few sentences in the 
spec to clear things up, sentences that I believe are deeply 
uncontroversial,  but people seem to be violently against saying 
anything direct on the matter. I'm more than happy to drop it and 
move on.

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Jul 2004 23:27:58 +0200

Bill de hÓra wrote:
> ...
> I guess not. People keep telling me it's a bug, but not why it's a bug. 
> In any case I've already signed up "it's a bug" view. But I will call it 
> a consensus view only. My point/question has always been whether this is 
> something that is *specified* somewhere. However many days into this 
> thread, I'm still not seeing that specification.
> ...

I think it's the basic nature of a namespace-aware tool that when you 
embed XML from a document X into a document Y, namespace names and local 
names of the embedded document will not change (maybe unless you 
specifically ask for it). Does this really need to spelled out expliticly?

Anyway, for DOM L2, this seems to follow from 
<http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#Namespaces-Considerations>:

"As far as the DOM is concerned, special attributes used for declaring 
XML namespaces are still exposed and can be manipulated just like any 
other attribute. However, nodes are permanently bound to namespace URIs 
as they get created. Consequently, moving a node within a document, 
using the DOM, in no case results in a change of its namespace prefix or 
namespace URI. Similarly, creating a node with a namespace prefix and 
namespace URI, or changing the namespace prefix of a node, does not 
result in any addition, removal, or modification of any special 
attributes for declaring the appropriate XML namespaces. Namespace 
validation is not enforced; the DOM application is responsible. In 
particular, since the mapping between prefixes and namespace URIs is not 
enforced, in general, the resulting document cannot be serialized 
naively. For example, applications may have to declare every namespace 
in use when serializing a document."

(note the 2nd sentence).

Best regards, Julian

---

From: Sam Ruby <[email-masked]>
Date: Sat, 17 Jul 2004 15:54:48 -0400

> That would have persuaded me, too!

Committed and deployed.

- Sam Ruby

---

From: Martin Duerst <[email-masked]>
Date: Sat, 17 Jul 2004 11:40:21 +0900

Hello Bill,

I think what you are saying is that there is no place in the namespace
REC that explicitly says that no-ns in line 3 is in no namespace, and
that therefore, you can put it in any namespace. But then the question
would be: but in which one? For example, both

  0   <outer xmlns="http://foo.example.org/">
  1   <atom:feed xmlns:atom="http://example.org/atom">
  2     <atom:content mode="xml">
  3       <no-ns xmlns="">Non-namespaced element</no-ns>
  4     </atom:content>
  5   </atom:feed>
  6   </outer>

and

  0   <outer xmlns="http://bar.example.org/">
  1   <atom:feed xmlns:atom="http://example.org/atom">
  2     <atom:content mode="xml">
  3       <no-ns xmlns="">Non-namespaced element</no-ns>
  4     </atom:content>
  5   </atom:feed>
  6   </outer>

would be legal according to that interpretation of the namespace REC.
But this would clearly lead to a contradiction, so transformations
of the above type can't possibly be legal according to the
namespace REC.

I think that you are probably right that it's rather difficult to
understand that from the namespace REC itself. It may be worth
looking at adding something like (just a draft):

"Note: elements without prefixes and not within the scope of a default
namespace declaration are in no namespace. Elements in no namespace
are different from elements with the same local name in any existing
namespace."

Norm, can I ask you as the co-chair of the XML Core WG to forward
this issue to the XML Core WG? Thanks!

Regards,    Martin.

At 21:58 04/07/16 +0100, Bill de hモra wrote:

>I said elsewhere that we should expect that our XML will get embedded. I 
>claim that your rule 1. must *always* apply - saying it doesn't apply is 
>seems only useful for the local case and is not robust.
>
>
>>Are you asking me
>Neither. I'm  saying I've seen this kind of markup in the wild in the same 
>way I've seen application libraries emit malformed XML in the wild. It 
>tends to gravitate around "envelope-oriented" markup. I have my suspicions 
>as to why but don't care to generalize.
>
>
>interpretation of namespaces to this bug. I keep going back to them and 
>reading them, but it just doesn't follow. And please stop saying "your 
>tool". I did not raise tools as being the issue here.
>
>>Does that help?
>
>I guess not. People keep telling me it's a bug, but not why it's a bug. In 
>any case I've already signed up "it's a bug" view. But I will call it a 
>consensus view only. My point/question has always been whether this is 
>We're way off topic by now. I was looking for a few sentences in the spec 
>to clear things up, sentences that I believe are deeply 
>uncontroversial,  but people seem to be violently against saying anything 
>direct on the matter. I'm more than happy to drop it and move on.
>
>cheers
>Bill

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 18 Jul 2004 12:44:59 +0100

>  3       <no-ns xmlns="">Non-namespaced element</no-ns>

Martin.

Those look the same... was one of the <no-ns xmlns=""> lines meant 
to be different or not there?

> looking at adding something like (just a draft):

You see, I think they can be legal. The fact that you/I/we think 
something  leads to a contradiction or doing so would just be silly 
doesn't imply it can't be possibly be legal. I claim the 
contradiction is the case and that it should be addressed with 
normative text; ie the bug is that the spec's 'axioms' are 
inconsistent/incomplete. To get around it I have to add extra 
information (a sense of silliness in one case, xmlns="" shrouding by 
default in another, or some other extra-interpretation) My position 
was to do that in the Atom spec, because it is something I might 
have sway over.

> are different from elements with the same local name in any existing

And yet - more interpretation is needed to make sense of how that 
should apply, so imo we haven't gotten anywhere. The problem occurs 
when an element that is not in a namespace is embedded in markup 
that has a default namespace. The scoping rules are incomplete for 
this case and the text above doesn't change that - how shall we 
*make* them different?

cheers
Bill

---

From: Martin Duerst <[email-masked]>
Date: Mon, 19 Jul 2004 09:57:08 +0900

At 12:44 04/07/18 +0100, Bill de hテ途a wrote:

>Martin.
>
>Those look the same... was one of the <no-ns xmlns=""> lines meant to be 
>different or not there?

Sorry, both xmlns="" are supposed to not be there. So it should have been

and

>doesn't imply it can't be possibly be legal. I claim the contradiction is 
>the case and that it should be addressed with normative text; ie the bug 
>is that the spec's 'axioms' are inconsistent/incomplete. To get around it 
>I have to add extra information (a sense of silliness in one case, 
>xmlns="" shrouding by default in another, or some other 
>extra-interpretation) My position was to do that in the Atom spec, because 
>it is something I might have sway over.

The Atom spec clearly should not try to fix the namespace spec,
or interpret it in any way that may risk to be different from what
the spec says. I have already asked Norm to take this back to the
XML Core WG and make sure it's clear, with whatever means the XML
Core WG deems necessary.

>And yet - more interpretation is needed to make sense of how that should 
>apply, so imo we haven't gotten anywhere. The problem occurs when an 
>element that is not in a namespace is embedded in markup that has a 
>default namespace. The scoping rules are incomplete for this case and the 
>text above doesn't change that - how shall we *make* them different?

I would claim that the scoping rules are complete. An element without
any namespace prefix but within the scope of a default namespace
declaration is in this default namespace.

Simply wrapping some XML that contains elements that are not in any
namespace with something that defines a default namespace therefore
changes the namespace of these elements from 'no namespace' to that
specific namespace, which means that it changes the nature of these
elements. So this operation, even if it looks less dangerous, is just
the same as going in and changing the URI in any arbitrary xmlns:foo
element: you change elements from one namespace to another. If you
don't want to do that, and it's pretty clear that you don't want to
do that except in very special cases, then it's clear that simply
wrapping some XML that contains elements that are not in any
namespace with something that defines a default namespace is
bad/dangerous.

Regards,    Martin.