Hi, Francis- You might want to take a look at the SVG-Wiki article on namespaces [1]; I wrote it to outline exactly why namespaces are necessary.
| How many of you just love to type about 100 extra keystrokes | for any SVG element you want to create or access? It's only a tiny bit more effort to use namespaced methods. Declare the NS in a global variable, like this: <svg xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' onload='Init(evt)'> <script><![CDATA[ var SVGDocument = null; var SVGRoot = null; var svgns = 'http://www.w3.org/2000/svg'; var xlinkns = 'http://www.w3.org/1999/xlink'; function Init(evt) { SVGDocument = evt.target.ownerDocument; SVGRoot = SVGDocument.documentElement; }; ]]></script> </svg> In fact, that's a basic template I use for my scripted SVG files. I just insert that using my TextPad clip library, and I never have to worry about declaring my globals or namespaces (unless I'm adding another XML dialect to the mix, of course). At that point, it takes 7 to 10 more "keystrokes" to use createElementNS and getAttributeNS; of course, with a clip lib or autocomplete, it's no more effort to use namespace-sensitive methods than their namespace-ignorant equivalents. As Jim correctly points out, attributes that are in the same XML dialect (like SVG) as the element are in the null NS; attributes from another dialect (XLink, HTML, MathML, XForms, etc.) must be in the proper namespace, as must elements from those dialects when in an SVG file. | Would your rather request: | | createElement("rect"); | | or, would you like to go through the mind-numbing process of | requesting: | | var svgns = 'http://www.w3.org/2000/svg'; | createElementNS(svgns, 'rect'); Let me reframe the question: Would you rather that every XML dialect had to be completely isolated, with no mixing of dialects at all? That would mean that each language would have to have every conceivable use built in to its syntax, and that only pre-planned uses for that syntax would have semantic value. There would be no modularity to XML, nor any chance to make composite documents. Rather, there would be *one* way this would work: if every dialect had to be carefully designed so that its element and attribute names were unique with respect to every other specification. So, a GIS language that was created after SVG could only use the attribute "x" in exactly the same sense as SVG designed into the attribute, or it would have to change its own syntax to "X" or "xVal" or something. And the next language that wanted to use an "x" attribute would have to check with every other previous language to make sure it wasn't already taken. So, FurnitureML could not use "table" because it was already taken by HTML... You see the implications of not having namespaces. Alternately, you could ignore all those restrictions, and still allow mixing of dialects. In this case, the question becomes: Would you rather use: createElementNS(svgns, 'path'); Or, when you are using SVG with your ParkML or FlightML, figure out some way of distinguishing each of those "path" elements from an SVG "path" element? It could be done, I'm sure, but it would be much more of a pain, and couldn't be standardized. More problematic is what the SVG viewer would do when it finds those extra "path" elements, and they don't have the proper syntax for it to parse; by the design of XML, the parser has to stop right there. You could not validate or ensure well-formedness. At that point, why are you bothering to use XML at all? Finally, what happens when you use your own custom attribute in an SVG element, say, "editable"... and the next version of SVG defines an "editable" attribute? At that point, your app is broken in any viewer that conforms to the new Spec. | If browsers and viewers require a developer to drain their | energy into providing such structural fuzzies, when in fact, | they can easily translate those requests into correct | formats, are not sensitive to the needs of developers. It's not just the browsers and viewers that are telling you to do this, it's XML. [1] http://svg-whiz.com/wiki/index.php?title=Namespace Regards- Doug [EMAIL PROTECTED] www.vectoreal.com ...for scalable solutions. ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/1U_rlB/TM --------------------------------------------------------------------~-> ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
