Re: [xml-dev] To namespace or not to Namespace ....

[Mukul Gandhi <gandhi.mukul@gmail.com>]

If an XML document is intended to be consumed by an application, which
others will use, I usually tend to use namespaces (I think, this may
be a good design practice).

When my XML documents, are meant to be used only by me (and in my
localized environment), I tend to avoid namespaces (as these XML
documents are not exposed to the outside world, & issue of name
collisions will likely never affect me).

I think, Here are some advantages & disadvantages of XML namespaces:

Advantages
1. It helps us avoid real name clashes with other XML vocabularies.
Moreover, namespaces may be used, if XML documents will be distributed
to others, when name collisions may really become an issue.

Disadvantages
1. Namespaces, increases the size of XML documents.
2. With namespaces, we need to be extra carefuly while writing
applications (all our programming expressions, querying & creating the
XML nodes must be namespace aware). This namespace-awareness overhead
(effort to create, and maintain) should be incurred, only if an
application requires it (i.e, if management of name collisions is
really needed).

Btw, here's a quick illustration of the choices that are probably
available, while using a notion of "name".

<name>Mukul</name>		(1)

<product:name>Hair Dryer</product:name>

<productName>Hair Dryer</productName>

<product>			(2)
  <name>Hair Dryer</name>
</product>


The design, (2) may still be bad (or may be right for somebody, and
sometimes right for me too!), because if we write an XPath expression,
//name then this tends to confuse concepts (1) & (2).

Interestingly, following representation of a chemical substance
<element>Sodium</element>

may conflict with the following XSLT instruction
<xsl:element ...

:)

On Tue, Apr 6, 2010 at 4:26 AM, David <dlee@calldei.com> wrote:
> I'm embarking on a project to create a schema (or more likely a collection
> of schema(i?) ) to model a dataset.
> This data is currently represented in a relational database as
> semi-normalized in about 20 tables.
> The underlying data is prety complex, but not in terms of
> attributes/elements but rather some hidden 'business knowledge' which is
> implied by
> fields with coded values and things like shared "string pools".
>
> The end result of this schema will be to be able to re-represent this data
> as XML for mainly internal use, although may be published in some form in
> the future
> (only to partners, not the general public).
>
> This is one of a handful of content sets that are already in XML or are
> already translated to XML, its the 'last dog' of enterprise business data to
> be translated to XML.
>
> Up until now we've never used namespaces. We've been blissfully unaffected
> by not using namespaces.   XQuery and XSLT and pure Java programs have had
> no problem with having no namespaces.   The data is typically in "silos" and
> while sometimes referenced together, is not of the "module" sort intended to
> be embedded in other XML documents, but rather fully standalone data (which
> may reference each other with loose couplings).
>
> I think I know the main reasons to use namespaces, and tons of reasons to
> not to ...
> Equally  confused by Balisage's opening talk last year that (pardon the
> paraphrase)
> "Best Practices for XML"
> 1) "Always use Namespaces:"
> N) "Never use Namespaces" ...
>
> So whats a poor XML geek to do ?
>
> Any *practical* suggestions ?
>
>
> --
> -------------------------
> David A. Lee
> dlee@calldei.com
> http://www.calldei.com
> http://www.xmlsh.org



-- 
Regards,
Mukul Gandhi