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

Re: WARNING: Namespace thread virus (new variant?)

• To: Jeff Lowery <Jeff.Lowery@c...>
• Subject: Re: WARNING: Namespace thread virus (new variant?)
• From: "Chiusano Joseph" <chiusano_joseph@b...>
• Date: Mon, 02 Feb 2004 15:16:35 -0500
• Cc: xml-dev@l...
• Organization: Booz Allen Hamilton
• References: <4827EC373E03DB44AC2AB3900430896B6724B9@c...>

Jeff Lowery wrote:
> 
> I'm working with someone else's XML serialization/deserialization code and

Sounds like one of those "I've got this friend who wants to know..."

> one of the requirements of  this particular implementation is that all
> serializable classes need set methods that take string  parameters (so the
> XML reader can know what method to call for setting attribute values without
> having the proper parameter type). In some cases, you wind up with two
> similar set methods:
> 
> void setFoo( double p)
> {
>    m_p = p;
> }
> 
> void setFoo( String p )
> {
>    m_p = Double.parseDouble(p);
> }
> 
> Well, this is too much bookkeeping for me. Although I could've written a
> schema for the XML data file and changed the reader to validate against it,
> I was in a quick and dirty mood so I just prefixed the attribute names with
> type information:
> 
> <qux d_foo="3.1416"/>
> 
> Where "d_" is XMLish hungarian for "this is a double". All very naughty of
> me, I'm sure, since now I have to parse the attribute name for type
> information.
> 
> Now, I'm thinking that while I'm at it I might as well do something for the
> elements that map to classes:
> 
> <qux d_foo="3.1416" classType="mycompany.product.qux"/>
> 
> All the original type information is now encoded in the XML so that a
> separate element-to-type map doesn't need to be created.  Java reflection
> gets me the rest of the way with just few lines of code (speed is obviously
> not of the essence).

Still working on that namespace prefix registry idea, I see ;)

> This has all been done a thousand times before in a thousand other places,
> and it's of questionable practice and all that; but frankly, my dear, I
> don't give damn: given the remedies, one could learn to prefer the disease.

The only gotcha that comes to mind is that non-namespace-aware
processors wouldn't be able to take advantage of this technique.

> While this is all lazy enough for me so far, it occurred to me I could take
> it one step further by using namespace declartions to encode type
> information:
> 
> <qux:qux d:foo="3.1416"
> xmlns:d="http://www.mycompany.com/java/primitives/double"
> xmlns:qux="http://www.mycompany.com/product/classes/qux"/>
> 
> This particular approach I don't recall seeing before, but it seems too
> obvious to be original. 

I know this doesn't help, but I'm sure I've seen this before yet I'm not
sure exactly where - if it comes to me I'll let you know.

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World

> Maybe it's that it's just too horrible an approach
> to be mentioned on a public forum by anybody with reputation to keep. While
> I can think of several strikes against it, none have quite convinced me that
> it's an utterly reprehensible idea.
> 
> Before I sin against all that's holy, I ask the list:
> 
> Who thought of this first?
> Was he shot for it?
> Why?
> Did his career recover?
> 
> -----------------------------------------------------------------
> 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://lists.xml.org/ob/adm.pl>

• References:
  • WARNING: Namespace thread virus (new variant?)
    • From: Jeff Lowery <Jeff.Lowery@c...>

• Prev by Date: RE: best practice for providing newsfeeds ?
• Next by Date: RE: WARNING: Namespace thread virus (new variant?)
• Previous by thread: WARNING: Namespace thread virus (new variant?)
• Next by thread: RE: WARNING: Namespace thread virus (new variant?)
• Index(es):
  • Date
  • Thread