Francis, Here is your example: A DOM scripting engine that handles multiple types of XML dialects, as opposed to a single one (such as the ASV3 scripting engine). Then, not only does it handle multiple dialects, but it enables seamless communication between the formats (as opposed to the current pain it is to do XHTML-SVG scripting). The scripting engine will handle the SVG scripting, as well as handle the embedded MathML and XHTML.
I remember way back when I was first learning XML, that namespaces were the most difficult thing and a hassle at best. Since then I have become aware of how powerful namespaces truly are and make use of them constantly. If you are going to drop the namespaces from getAttributeNS, why not drop namespaces from XSLT as well? Hrm, that wouldn't work would it hey? So, Fracis, I'm afraid that it is really YOU who is the one thinking inside of the box. You are still stuck in the stone age of XML implementations. That where XML dialects were discrete sets and had no mixing of content. Take some time and do your homework: http://www.w3.org/2004/CDF/. If you are such a critic of the language, why not put your money where your mouth is and join the W3C and get in on some of these working groups? Or can you only attempt to cause controversy on a developers list? I doubt that they will change the way things work just because you made a couple of posts to svg-developers. Be proactive instead of reactive. That will solve both our problems: 1. You will have an answer to your setAttributeNS question 2. I will not have to read through so much spam on this list to try to help people out who are here for help, not to cause controversy. My two cents. Alastair --- In [email protected], "Francis Hemsher" <[EMAIL PROTECTED]> wrote: > JD, > Finally, someone who can think outside the box! > > Without further ado, I also challenge anyone to provide a namespace > process of today, whereby I can't present it in a more intuitive > method, without the use of namespace. > > Try me, > Francis > > --- In [email protected], "benamou" <jean- > [EMAIL PROTECTED]> wrote: > > Francis may have a point : > > > > why setAttribute(attr,prop) does not default > > to setAttributeNS(CurrentDocNS,attr,prop) ??? > > JD > > > > > > ----- Original Message ----- > > From: "Doug Schepers" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Thursday, October 06, 2005 1:57 AM > > Subject: RE: [svg-developers] setAttributeNS is dumb,dumb,dumb! > > > > > > > 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. > > > > > > > > > > > > > > > ----- > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > ------------------------ 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/
