OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Partyin' like it's 1999

[ Lists Home | Date Index | Thread Index ]

Alessandro Triglia <sandro@mclink.it> asks:

> > From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
> > 
> > Bullard, Claude L (Len) <len.bullard@intergraph.com> asks:
> >  
> > > Ok.  Any parties interested in posting their favorite five
> > > bad problems with XML in order here?  I wonder what the 
> > > consensus is on the top two.  (XML, not XML apps like 
> > > XSD.)
> > 
> > 1) Namespaces
> > 2) Namespaces
> > 3) Namespaces
> > 4) Namespaces
> > 5) Namespaces
> 
> 
> When people complain about namespaces, do they mean that 
> namespaces should not exist at all?  Do they think they are 
> useless?  Or do they think they should be replaced by 
> something else?  Or do they have in mind some simple changes 
> to the syntax, such as using URI/localname pairs everywhere?
> 
> Alessandro

Good question. Conceptually I think there is a need for something like
name spaces.  I think the current implementation is painful.  Some of
the pain is at the Java API level.  Some of the pain is in every day
common use.

We initially divided some major portions of our system up with name
spaces.  When writing XSLT one of the first things we do in almost every
case is run a transform that strips out the namespaces so that you
subsequently don't have to worry about them. 

In practice they haven't bought us anything, yet. We may, someday
actually need to do some external interchange on some of the data that
includes name spaces, maybe then we'll benefit.  In the mean time they
just hurt us.  

Some might say that we got what we deserved by doing premature
optimization.  But given the way namespaces work you've got to make the
decision to use them at the architecture/design phase, not at the point
you actually have naming conflicts. Going back and retrofitting name
spaces into an architecture is perhaps even more painful than going back
and stripping them out.

Example, we've been testing a major release or our main app for about 2
months.  All major bugs have been quashed, we're so close to final
release we actually have a target date we feel good about.  Just
yesterday we had to extend a Java class so that we could handle yet
another corner case.  The underlying problem should have just resulted
in a simple substitution of class X with class Y, but nope, different
levels of element nesting combined with name spaces prevented that from
happening.





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS