RE: [xml-dev] A multi-step approach on defining object-orientednature of DOM

["Dare Obasanjo" <dareo@microsoft.com>]

Good list. I notice that most of them would be avoided if people just
accepted that default namespaces are evil[0,1] and kept away from them.
Let's take them in turn 

1.) If default namespaces didn't exist then the dev would have only had
to memorize the simple rule "unprefixed names are in no namespace"
instead of the current confusion. 

2.) This is also a difficulty I have encountered which should be no. 3
on my list of difficulties people face in schema. My next Extreme XML
column on MSDN is aimed at explaining how these work so as to reduce the
confusion inherent in utilizing this aspect of schemas. 

3.) The W3C XML Schema working group confused matters greatly by making
qualified mean "have a namespace name" instead of "have a prefix" which
is what was meant in the Namespaces in XML REC. 

4.) Depends on what DOM you use. The following code works fine in
creating a namespace decl in the DOM for me 

	using System;
	using System.Xml;

	public class Sample
	{
	  public static void Main()
	  {
	    XmlDocument doc = new XmlDocument();
	    doc.LoadXml("<book genre='novel' ISBN='1-861001-57-5'>" +
      	          "<title>Pride And Prejudice</title>" +
            	    "</book>");

	    //Create an namespace declaration.
	    XmlAttribute attr = doc.CreateAttribute("xmlns",
"http://www.w3.org/2000/xmlns/";);
	    attr.Value = "http://www.example.com/book/";;
          
	    //Add the new node to the document. 
	    doc.DocumentElement.SetAttributeNode(attr); 
	        
	    Console.WriteLine("Display the modified XML...");         
	    doc.Save(Console.Out); 
	  }
	}

5.) It's a "namespaces are URIs not URLs" issue. 

6.) But isn't it a java.net.URI or is this pre J2SE 1.4? 

7.) Yeah, this is more of a giggle than a problem. 
 

[0] http://lists.xml.org/archives/xml-dev/200208/msg00111.html
[1] http://lists.xml.org/archives/xml-dev/200208/msg00219.html

-- 
PITHY WORDS OF WISDOM 
Putting in a request to go home early is the best way to jinx yourself
and end up working overtime.     

This posting is provided "AS IS" with no warranties, and confers no
rights. 



> -----Original Message-----
> From: Amelia A Lewis [mailto:amyzing@talsever.com] 
> Sent: Tuesday, August 20, 2002 7:27 PM
> To: Dare Obasanjo
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] A multi-step approach on defining 
> object-orientednature of DOM
> 
> 
> On Tue, 2002-08-20 at 20:23, Dare Obasanjo wrote:
> > The fact that namespace declarations and in-scope namespaces are 
> > treated differently in various W3C specs is something I am familiar 
> > with and have written about[0]. However this is not 
> something that is 
> > equates to DIFFICULTY in dealing with namespaces given that 
> Joe Blow 
> > developer doesn't spend his time reading W3C specs. I read 
> on average 
> > 10 - 20 posts a day on our XML related newsgroups and when I hear 
> > about DIFFICULTY with namespaces it typically takes two flavors of 
> > questions
> 
> If I interpret this correctly, it is a challenge to give 
> real-life examples of difficulties, on the part of 
> developers, in dealing with namespaces.
> 
> All right.  Some background: I work for a corp (no, not 
> Talsever) that does a great deal of B2B and EAI stuff.  The 
> corp is moving toward XML as data representation (customer 
> demand, largely), and so purchased the company I hired into, 
> a little XML startup.  Lots of serious XML expertise here; 
> lots of serious enterprise expertise (and close attention to 
> performance issues) in the parent.  I get called upon to 
> straighten things out when someone, probably very sharp, 
> possibly antipathetic towards XML (the usual performance 
> anxieties) gets into a bind with our APIs and toolchain, or 
> public APIs that we recommend.
> 
> 1. Carefully constructed code, complete with a comment that 
> the "bug has been reported to the Xerces team with no 
> response", to "fix" the assignment of names of unqualified 
> attributes by Xerces.  The author was so convinced that 
> unqualified attribute names needed to be coerced into the 
> default namespace that he wrote some quite nice code that does so. 
> Software that uses this code tends to behave peculiarly, to 
> say the least (it's fine as long as there is no default 
> namespace; then the attributes stay unqualified (the comment 
> says this part is still "to do", fortunately)).  Encountered 
> once, but interesting evidence of powerful convictions of how 
> namespaces "ought to work" by a very competent (but not 
> highly XML skilled) developer.
> 
> 2. API users who have written schemas using the usual 
> defaults (elementFormDefault qualified, attributeFormDefault 
> unqualified) get into a fidget when their instances don't 
> validate (because they assign namespace-qualified names to 
> attributes, instead of unqualified ones). 
> In one of the three occasions that I recall, the developer 
> became increasingly hostile to discussion of the behavior of 
> attributes, leading to:
> 
> 3. API users who have generated schemas with 
> attributeFormDefault qualified.  Testing with namespaced 
> attributes works great, but when they try to "simplify the 
> serialization" by using the default namespace, everything 
> breaks.  This time it's because the namespace isn't declared, 
> and trying to explain that elements can be unqualified and in 
> a namespace, but attributes can't, is a somewhat painful 
> exercise.  Tow occasions, one of them a direct result of 
> revision of schema due to item #2; after that a different 
> developer was given responsibility for the XML problem and 
> the first became a general opponent XML for any use.
> 
> 4. Namespace mangling due to the ability to define an 
> attribute in DOM which, on serialization, turns into a 
> namespace declaration.  I forget how many times I've dealt 
> with this one, at least five; sometimes it's done on purpose 
> by one developer (as a hack to attach a namespace 
> declaration, by adding the attribute and forcing a reparse) 
> and broken by a maintainer (who wants to improve performance 
> by removing the "redundant" parse).
> 
> 5. Lots of irritation that the namespace URI isn't the 
> location of the schema, and that schemaLocation and friends 
> aren't reliable.  Is that a namespace issue?
> 
> 6. Several instances of the use of java.net.URL for 
> normalization of a namespace URI that breaks comparability.  
> This leads to explanations that "a namespace URI is *not* a 
> [java.net.]URL!"
> 
> 7. One rather embarrassing attempt to assign the default 
> namespace to the URI of the namespaces rec.  This was because 
> the person didn't think that they could use the xmlns prefix 
> without declaring it, so they tried to declare it, which 
> instead put all of the elements into the XML Namespaces 
> namespace, which got really surreal.  Major ha-ha, and the 
> developer was perfectly willing to be corrected, but a rather 
> suggestive sort of error (this was a developer a little more 
> willing to incorporate XML, who got just enough knowledge to 
> be dangerous).
> 
> *sigh*  I envy the folks who get to give presentations, 
> instead of doing crisis management/problem resolution.  Items 
> two through four I've encountered often enough to think of 
> them as problems, but documenting stuff only helps when folks 
> read the docco.  Five is cataloging, six is related to the 
> fact that namespaces are case-sensitive strings rather than 
> URLs, and seven is more of a giggle than a problem.
> 
> Does that help any?
> 
> Amy!
> -- 
> Amelia A. Lewis       amyzing@talsever.com      alicorn@mindspring.com
> You like the taste of danger, it shines like sugar on your 
> lips, and you like to stand in the line of fire just to show 
> you can shoot straight from your hip. There must be a 1000 
> things you would die for; 
> I can hardly think of two.
> 		-- Emily Saliers
>