[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Partyin' like it's 1999

  • To: "Joshua Allen" <joshuaa@m...>,"Robert Koberg" <rob@k...>,"Bullard, Claude L \(Len\)" <len.bullard@i...>
  • Subject: RE: Partyin' like it's 1999
  • From: "Dare Obasanjo" <dareo@m...>
  • Date: Tue, 26 Oct 2004 23:19:25 -0700
  • Cc: <xml-dev@l...>
  • Thread-index: AcS7r+tRNVA24TaRQdaMf0jYO/rSXwAMmtfAAAKkYKg=
  • Thread-topic: Partyin' like it's 1999

php dom innerxml
My personal favorite and the cause of much consternation over the past few months has been "What the heck is supposed to happen when the user inserts, edits or deletes namespace declarations using an API like the DOM?". Nobody knows. All we know for sure is that whatever your favorite DOM implementation does is probably not what some users expect. 
 
-- 
PITHY WORDS OF WISDOM
If you don't change your direction, you may end up where you were headed. 

________________________________

From: Joshua Allen [mailto:joshuaa@m...]
Sent: Tue 10/26/2004 10:32 PM
To: Robert Koberg; Bullard, Claude L (Len)
Cc: xml-dev@l...
Subject: RE:  Partyin' like it's 1999




> -----Original Message-----
> From: Robert Koberg [mailto:rob@k...]

> I don't get the /problem/ with namespaces.

Joe English and Bill de Hora have discussed some issues.  Default
namespace leads to dual "modes" of parsing, don't apply to attributes (I
agree with Joe, would rather just have everything be an opaque string).


No way for a parser to return a single attribute value without parsing
all the way to the end of the start tag.  For example, if you have:

<foo x:id="a" y:id="a" ...insert a bajillion attributes here...
xmlns:x="foo" xmlns:y="foo">

You have malformed XML right at the beginning, but the parser doesn't
know to throw (and cannot even accurately report the first or second
attribute) until it has parsed a bajillion other attributes first.  Why
is it allowed for the xmlns to come *after* the first use of the prefix
anyway (order of attributes doesn't matter, so to hell with perf)

What if the xmlns declaration is on an ancestor node, and you call
.InnerXml on DOM from a child node.  Should the .InnerXml represent the
text content of the subtree, in which case it would lose the namespace
decl if written to text, or should it insert an extra xmlns decl?  You
get into all sorts of crazy situations; dumping entire set of NS decls
in scope on XSLT output, generating bogus prefixes on output.

QNames in content are another abomination brought on by namespaces.

And then we have the example of people doing just fine with XML without
ever putting their data in any namespace at all.  What a mess.

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>




PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.