Query:

The XAML loaded into an XML document just fine. It's well formed, and the Image item does exist inside the Application.Resources section. I just couldn't figure out what the heck was going on. Then, it hit me - in a flash of the blinding, bleeding obvious. These tags don't actually exist on their own. They are part of the XAML namespaces, which opens up a whole new line of things you need to do. Basically, in order to perform this query, I needed to import the same XAML namespaces into my XML document - and then I should be good to go. Right?

Well, not quite. The above query also needs to change slightly. Without, the namespaces in, this query still doesn't work. So the first thing we need to do is add the namespaces into the query and we get:

and the code to load the namespaces in:

private static XmlNamespaceManager GetNamespace(XmlDocument doc)
{
  XmlNamespaceManager mgr = new XmlNamespaceManager(doc.NameTable);
  mgr.AddNamespace("presentation", http://schemas.microsoft.com/winfx/2006/xaml/presentation);
  mgr.AddNamespace("xaml", http://schemas.microsoft.com/winfx/2006/xaml);
  return mgr;
}

In the username field the format is: "onepurdue\username"

Try it here at the home page of the intranet: https://share.tech.purdue.edu/

Say for instance I have a resource called Posts and I want to generate an admin front-end to it. All I need to do is change to the application directory and type:

merb-gen resource_controller admin/posts

This creates a subfolder called 'admin' within your controllers and a new posts controller within that to handle all the CRUD functions. However, on MERB 0.9.5, the controller is missing the module keyword and if you try to run the above you would receive a namespace or controller not found error.

To fix this, open up 'admin/posts' controller and add 'module Admin' to the file:

module Admin

class Posts < Application

....

end

end

Next add the required namespace to the 'config/router.rb' file:

Merb::Router.prepare do |r|

r.namespace :admin do |admin|

admin.resources :posts

end

end

Fire up your app and it should all work. I'm not certain if this is fixed in subsequent versions of Merb but I did notice a ticket has been submitted for nested namespaces error. If anyone reading this has more information on the official line, please do leave a comment

NEWS FLASH:

Just received an up-to-date comment from one of the MERB framework developers who read this post and confirmed that the latest version of 'merb-gen' has been fixed to prevent the error above. So upgrade your version of Merb to prevent it. And you still have to add in the namespace in your router file manually.

(:

=====================================
Description: xquery to remove namespaces from an xml
@author Arun Pareek
=====================================
$Resource/XQUERY/stripNamespace.xq  $

:)

declare variable $inputRequest as element() external;
declare function strip-namespace($inputRequest  as element()) as element()
{
element {xs:QName(local-name($inputRequest ))}
{
for $child in $inputRequest /(@*,node())
return
if ($child instance of element())
then strip-namespace($child)
else $child
}
};

document
{ strip-namespace($inputRequest )}

Before explaining the code let me give a small example of how this piece of code works.

Input XML with Namespaces

<TestXML xmlns:sp-en="sch.soap.org">
<ZBAPI_COIB.ZBUR xmlns:sp-en="sch.soap.org">
<I_OUTPUT xmlns:sp-en="sch.soap.org"/>
<RETURN xmlns:sp-en="sch.soap.org">
<item xmlns:sp-en="sch.soap.org">
<TYPE xmlns:sp-en="sch.soap.org">S</TYPE>
<CODE xmlns:sp-en="sch.soap.org"/>
<MESSAGE xmlns:sp-en="sch.soap.org"/>
<LOG_NO xmlns:sp-en="sch.soap.org"/>
<MESSAGE_V1 xmlns:sp-en="sch.soap.org"/>
</item>
<item xmlns:sp-en="sch.soap.org">
<TYPE xmlns:sp-en="sch.soap.org">S</TYPE>
<CODE xmlns:sp-en="sch.soap.org"/>
<MESSAGE xmlns:sp-en="sch.soap.org"/>
<LOG_NO xmlns:sp-en="sch.soap.org"/>
<LOG_MSG_NO xmlns:sp-en="sch.soap.org">000000</LOG_MSG_NO>
<MESSAGE_V1 xmlns:sp-en="sch.soap.org"/>
</item>
</RETURN>
</ZBAPI_COIB.ZBUR>
</TestXML>

And the Output of the Xquery is

<TestXML>
<ZBAPI_COIB.ZBUR>
<I_OUTPUT/>
<RETURN>
<item>
<TYPE>S</TYPE>
<CODE/>
<MESSAGE/>
<LOG_NO/>
<MESSAGE_V1/>
</item>
<item>
<TYPE>S</TYPE>
<CODE/>
<MESSAGE/>
<LOG_NO/>
<LOG_MSG_NO>000000</LOG_MSG_NO>
<MESSAGE_V1/>
</item>
</RETURN>
</ZBAPI_COIB.ZBUR>
</TestXML>

As you can see the code is very much self-explanatory. The Xquery snippet expects an xml input to it. The Xpath entity crawls through each of the elements in the input and returns just the child elemnt and discards the namespace. A very much similar to recursive fucntions in C/C++.

Enjoi :-)

Source to download: http://mustafaturan.net/download/lectures/csharp/strip_tags_csharp.txt

// as a namespace do not forget to add: using System.Text.RegularExpressions;
static string strip_tags(string str, string allowed_tags)
{
/*
// Coder: Mustafa Turan
// Date: 05.09.2008
// Contact:
// http://mustafaturan.net/
// http://mustafaturan.wordpress.com/
// wm [ #at# ] mustafaturan.net
// Licence: GNU and MIT Licence
// EXAMPLES
// --->     function call1: strip_tags("<a href=\"asdadsadsad.html\">doctor</a> <p>pirasa</p> <img src=\"asd.jpg\" /> <h1>hey you</h1>", "<a>,<p>,<img />")
// --->     result: <a href="">doctor</a> <p>pirasa</p> <img src="asd.jpg" /> hey you
// --->     function call2: strip_tags("<a href=\"asdadsadsad.html\">doctor</a> <p>pirasa</p> <img src=\"asd.jpg\" /> <h1>hey you</h1>", "")
// --->     result: doctor pirasa hey you
*/

// START
// pattern for getting all tags
string pattern_for_all_tags = "</?[^><]+>";

// pattern for allowed tags
string allowed_patterns = "";
if(allowed_tags!=""){
// get allowed tags if any exists
Regex r = new Regex("[\\/<> ]+");
allowed_tags = r.Replace(allowed_tags,"");
string[] allowed_tags_array = allowed_tags.Split(',');
foreach (string s in allowed_tags_array)
{
if (s == "") continue;
// Definin patterns
string p_1 = "<" + s + " [^><]*>$";
string p_2 = "<" + s + ">";
string p_3 = "</" + s + ">";
if(allowed_patterns!="")
allowed_patterns += "|";
allowed_patterns += p_1 + "|" + p_2 + "|" + p_3;
}
}

// Get all html tags included on string
Regex strip_tags = new Regex(pattern_for_all_tags);
MatchCollection all_tags_matched = strip_tags.Matches(str);

if (allowed_patterns != "")
foreach (Match m in all_tags_matched)
{
Regex r_1 = new Regex(allowed_patterns);
Match m_1 = r_1.Match(m.Value);
if (!m_1.Success)
{
// if not allowed replace it
str = str.Replace(m.Value, "");
}
}
else
// if not allow anyone replace all
str = strip_tags.Replace(str, "");
return str;
}

From the documentation:

Properties now have three attributes, getter, setter and deleter, that are decorators providing useful shortcuts for adding a getter, setter or deleter function to an existing property. You would use them like this:

class C(object):
    @property
    def x(self):
        return self._x

    @x.setter
    def x(self, value):
        self._x = value

    @x.deleter
    def x(self):
        del self._x

class D(C):
    @C.x.getter
    def x(self):
        return self._x * 2

    @x.setter
    def x(self, value):
        self._x = value / 2

I found this very interesting. If you're, for some reason, a frequent reader of this blog, you'd remember how in a previous post I suggested a hack to allow namespaces inside Python classes. However, it was largely incomplete because I couldn't get it to work for properties. Perhaps now I can?

Now, don't let that pretty decorator syntax mislead you. Doing:

    @x.setter
    def x(self, value):
        self._x = value

is exactly identical to doing:

    def x_set(self, value): # Name changed to preserve 'x'
        self._x = value
    x = x.setter(x_set)

And this is exactly what I was missing to complete my code.

So here is the new make_namespace, applying also to properties:

(This was only tested on Python 3, but should also work for Python 2.6. It will not work on version 2.5 or lower)
[sourcecode language='python']
import types
def make_namespace(self, ns_cls):
"This code iterates all functions and properties in ns_cls and binds them to self"
for attr_name in dir(ns_cls):
attr = getattr(ns_cls, attr_name)
if type(attr) == types.FunctionType:
setattr(ns_cls, attr_name, attr.__get__(self) )
elif type(attr) == property:
setattr( ns_cls, attr_name, attr
.getter( lambda x : attr.fget(self))
.setter( lambda x,v: attr.fset(self,v))
.deleter(lambda x : attr.fdel(self))
)
return ns_cls()
[/sourcecode]

Notice that I can chain getter, setter, and deleter, because they all return a property object.

And here is a possible usage:
[sourcecode language='python']
class YetAnotherGuiWindow:
def __init__(self, pos, size, ...):
...
self._size = size
self.spatial = make_namespace(self, self.spatial)

class spatial:
...
def _get_size(self):
return self._size
def _set_size(self, size):
self._size = size
size = property(_get_size, _set_size)
...

...
# Meanwhile, in my console
>>> g.spatial.size = (100,100)
>>> g.spatial.size
(100, 100)
>>> g.spatial.size = (140,10)
>>> g.spatial.size
(140, 10)
>>> g._size
(140, 10)
[/sourcecode]

I hope you'll find this useful!

An ontology is concerned with the categorization of things.  A "thing" can be just about anything -- a person, a company, a particular news story, a video, an application, or a web page.  Ontology is a broad concept and subsumes taxonomy and folksonomy. Google Search delivers relevant results because it leverages a massive corpus ontological information about web sites and entities.  PageRank is but one device in the search arsenal that infers ontological information about both the classification and quality of a page.

A taxonomy is a more formal construct concerned with the ordering of things, usually in a hierarchical structure.  Yahoo's Directory is a taxonomic organization of the web, for example.  The Open Directory Project (DMOZ) is also a taxonomic organization of the web, but rather than leveraging a group of internal "surfers" as Yahoo! did, DMOZ is an open source directory.  

In the early days of tagging, the term folksonomy emerged to describe a non-hierarchical ordering of things through collaborative input.  For example, when a user tags a photo in Flickr, she is creating an informal taxonomy.  These tags are aggregated to help consumers find photos -- either by "tag surfing" or by making search more precise as a result of better meta-data.

Who needs philosophy?

Let's review some of the big wins over the past decade on the consumer internet.

Yahoo!  

Started with a directory built by web surfers.  Employed a chief taxonomist to overlook the organization of the directory.

Google 

As the amount of data on the web grew exponentially, taxonomies will too structured to keep up -- a more flexible ontology was required.  Google replaced the directory (a taxonomy) with search (a less formal ontology).

Facebook

Social networks are ontologies.  When you search for a name (e.g., Joe Smith) on Google, you get the NBA player.  When you search for Joe Smith on Facebook, you are far more likely to find the Joe you are looking for.  When search for Joe Smith on Flickr, you get the photo of this man.  The Joe Smith tag on Flickr is text.  When you tag a photo on Facebook, you are encouraged to highlight objects (usually a face) and then select a name from your friends list.  The value of the tag "Joe Smith" tag on Facebook is far more valuable than the "Joe Smith" tag on Flickr because it has more information embedded in the tag.

And don't forget that the Internet is the ultimate taxonomy -- DNS is a system that maps human-readable names (e.g., http://laserlike.com/) to an IP address (http://76.74.254.123/, which is the IP address for Wordpress).

 Opportunities.

If you can invent something that improves the information about a big class of things on the web, you can have a massive impact.  

For example, there really isn't a dominant ontology for organizations.  We have tickers for the ~10,000 public companies in the United States.  What about the other 8MM businesses in the US?  Nonprofits and clubs?  And the rest of the world?  There are firms who have tried to create some of this information (e.g., Hoovers, Crunchbase, VentureWire).   Once you have a solid ontology for this type of thing (ideally with some sort of namespace), you can pivot around it to create massive value.  You could munge together the social graph with the organizational namespace for a definitive guide of who belongs to which organizations.  How about the automated inclusion of hypertext links (ala Yahoo! Shortcuts) in every bit of text on the web linking to that organizational namespace?  And clustering groups of organizations for the purposes of discovery and analysis?

How about a location-based namespace?  You have some of this today with addresses and zip codes.  But what if you could take the GPS coordinates of every fixed object on the planet and append a human-readable name (like DNS does with IP addresses)?  And not only based on horizontal location, but also including vertical location (e.g., the 30th floor of the Bank of America building in SF)?  Perhaps you append a location code to an URL (e.g., bankofamerica.com/sf/555-30)?

In shopping, certain categories like music and books have formal ontologies (e.g., ISBN codes).  But most categories lack universal codes (or SKUs), requiring every retail and online site to create their own ontology -- a pair of Levis 501 Jeans may have the code Levi501_2008 at one retailer and LS12345 at another.  Ebay has employed a very loose ontology due to the fact that they continuously have sellers adding and subtracting products from inventory.  This makes finding a product and comparing prices far more laborious than is ideal.

These are simply examples that come to mind as I type.  Any other ideas about categories that would benefit from improved classification?

 İnternet üzerinde gezinir iken sürekli bir takvim olsa da namespace leri görsem diye yakınır iken bulduğum bu mucizevi bir imaj buldum sizin ile paylaşmak istedim umarım yardımcı olacaktır.

Alper TAYFUN

Se viene PHP 5.3 así como quedo, algo feo para mi gusto. Veamos a que atenerse en cuanto a namespaces.

Los namespaces de PHP son bastante distintos a similares construcciones de otros lenguajes. Consideremos este escenario: dos desarrolladores PHP están trabajando en componentes distintos, sin posibilidad de saber uno lo que hace el otro, ¿cómo evitar que al integrar los dos componentes falle la aplicación por colisiones de nombres? Una opción es hacer lo que venimos haciendo hasta ahora, prefijar todos los nombres con el nombre del componente. La nueva opción es indicar como namespace el nombre del componente, que básicamente es lo mismo que el prefijo (porque más que eso no hace).

Namespace ahora es un keyword

Y sí, rompieron la compatibilidad hacia atrás, y no es un cambio mayor de versión.

Después de varias idas y vueltas, cotejando el impacto de usar un keyword u otro, quedo namespace como keyword. No importa cual hubieran elegido entre los dos favoritos, package y namespace, cualquier de los dos son palabras de uso frecuente (por ejemplo, xml tiene namespaces). Cualquier clase que tuviera como nombre de variable a namespace, ahora va a dejar de funcionar. JODANSE.

Consejo: nada que hacer. Refactoring. Con suerte no usas namespace como nombre.

Lo que hubiera estado bueno: no hacia falta tomar un keyword nuevo. Había opciones que no requerían un statement para indicar el namespace. Y si no quedaba otra... hubiera sido para PHP6 el cambio.

El namespace implicito y especial de nombres internos

Segundo gotcha! del tema de los namespaces. Hay todo un conjunto de nombres internos, que corresponden a funciones y clases de la librería estándar y extensiones, que debería ser "visible" desde cualquier namespace, para que uno pueda fácilmente refactorizar código sin namespace a código con namespace. O sea, si yo indico que trabajo en un namespace igual quiero poder usar count(), strlen(), etc tal y como siempre lo hice.

El tema acá es que una función o clase interna se puede "sobrecargar" en un namespace, o sea, redefinirla. Esto es útil para los componentes que definen su propia clase de excepciones, por ejemplo. Pero hay que estar atento que la función count() adentro de un namespace puede que no devuelva la cantidad de elementos de un array sino lo que al desarrollador de ese componente le parecio que count() debía hacer.

Consejo: usar namespaces solo para clases, evitar declarar funciones dentro de namespaces a menos que uno sepa exactamente lo que está haciendo. También uno puede referirse inequívocamente a la función del espacio interno anteponiendo ::, por ejemplo, ::count().

Lo que hubiera estado bueno: que no se pueda sobrecargar los nombres del espacio interno, pero que exista un namespace inicial con ciertos nombres que resulta práctico sobrecargar, por ejemplo: Exception. De esta manera se evitan prácticas que pueden resultar perjudiciales y no tienen sentido (como sobrecargar las funciones básicas), y se le da la flexibilidad al desarrollador para sobrecargar los nombres que si tiene sentido sobrecargar.

Colisión de nombres no detectada, función pisa metodo estatico

Acá la pregunta que seguro se van a hacer todos es "¿cómo? ¿no era que con esto resolvíamos el tema de las colisiones de nombres?", bueno, no del todo... hay un "pequeño" problema.

Supongamos que tengo una función llamada bar() en el namespace test::foo. Ahora supongamos que tengo una clase llamada foo, que tiene un método estático llamado bar(), y se encuentra en el namespace test. Históricamente en PHP los nombres de funciones y nombres de métodos no tenían chances de colisionar, pero... a ver quien me dice a que corno apunta test::foo::bar()!

Lo cierto es que esto que acabo de ejemplificar es un caso de colisión de nombres del que php5.3 no te da aviso alguno. Si intentas el ejemplo, PHP va a llamar a la función, no al método estático. De manera que ahora existe una manera de "pisar" métodos estáticos, o sea, desde otro namespace se vuelve inaccesible el método estático de la clase.

Consejo: no declarar funciones en namespaces (¿para qué?) o evitar en lo posible anidar namespaces.

Lo que hubiera estado bueno: realmente no hacia falta namespaces que contuvieran funciones ni tampoco varios niveles de anidación. Cuanto más simple, mejor.

Multiples namespaces en un mismo archivo

No se si esto esta documentado o explicado en detalle en la documentación, pero se puede declarar el namespace más de una vez en una archivo. Esto fue para resolver una situación muy ad-hoc y es un moco feo que no debería haber llegado a producción. Se puso para que se pudieran concatenar archivos php para generar un único archivo que contuviera todo, una optimización medio fea que ya no tiene sentido teniendo a disposición phar.

Consejo: por el amor de todo lo que es buen diseño, ¡NO DECLAREN EL NAMESPACE MÁS QUE UNA SOLA VEZ POR ARCHIVO! Y castiguen a todo el que lo haga.

Lo que hubiera estado bueno: que quitaran esto.

El "use" (import/alias de nombres) solo funciona para clases y namespaces.

Otra de las cosas que no se arreglaron. El use es la herramienta más útil que nos da esto de los namespaces, y en realidad ni siquiera nos hace falta usar el resto. El "use" es básicamente un generador de alias de nombres, con el podemos hacer de esos nombre realmente largo en nombre cortos, por ejemplo:

use Really_Long_Long_Long_Name as ShortName;

Pero hay un tema, solo se puede renombrar clases y namespaces, pero no así funciones ni constantes, que son elementos que también se encuentran dentro de un namespace. O sea, sirve para acortar nombres de clases, que es genial y que es lo que queríamos, pero no para acortar nombres de funciones o constantes. Con esto surge la pregunta: entonces, ¿para qué esta la opción de tener funciones y constantes dentro de un namespace?

Consejo: creo que lo dije ya, esto de los namespaces en PHP solo viene bien para usarlos con clases.

Lo que hubiera estado bueno: que se enfocaran más en esta herramienta que era lo que realmente importaba.

El "use" no permite importar todo un namespace

Esto es lo que todos los que usan namespaces en otros lenguajes van a pedir seguro, pero no hay caso... esto es PHP! (cualquier alusión a la novela gráfica 300 es pura coincidencia). Hay que entender que el use no es un import, en realidad es solo una manera de asignar nombres más cortos dentro del scope de un archivo php.

Impacto en performance

Infaltable este tema. La promesa era que la implementación de namespaces no iba a afectar la performance, que el mayor impacto iba a ocurrir en la compilación, de manera que con un opcode cache se podía salvar el overhead. Lo cierto es que esto no es así, algo hay que pagar por el uso de los namespaces. De todas maneras estamos hablando de mediciones en el rango de las millonesimas de segundo. No hay sistema PHP que tenga suficiente procesamiento como para que se note realmente el impacto del uso de namespaces. Igual vale la pena notar que nada es gratis.

En los análisis de tiempo que hice observe impactos de performance en llamadas a métodos estáticos y en la construcción de objetos, lugares donde la lógica de resolución de nombres tiene sus vueltas (en realida solo esperaba un impacto importante en las llamadas estáticas, no comprendo porque hay un overhead importante con la construcción de objetos).

De PHP5.2 a PHP5.3 sin declarar namespace, el impacto en las llamadas a métodos estáticos es mínimo. Tarda un 4% más (que es solo 1 millonésima de segundo medido en mi pc: de 25 millonésimas a 26).

Declarando un namespace, el impacto en las llamadas a métodos estáticos es de un 20% más de tiempo (5 millonésimas de segundo en mi PC: de 25 millonésimas a 30).

Declarando un namespace, el impacto en la construcción de objetos es de un 33% más de tiempo (3 millonésimas de segundo en mi PC: de 9 millonésimas a 12).

Consejo: no creo que haya que preocuparse por el overhead, pero este existe, cuando se empiece a probar en producción se vera si hay que considerar o no el impacto en performance. Si no es aceptable el overhead, no hace falta usar namespaces, con el prefijo en nombres nos veníamos arreglando bastante bien, y el "use" alivia el tema de los nombres largos aún si no usamos namespaces (notese que el "use" se resuelve siempre en compilación así que el overhead lo amortigua el opcode cache, por lo que no es una preocupación).

¿Y los features de encapsulación?

La otra pregunta que varios se van a hacer es qué sentido tienen los namespaces si no puedo ajustar los limitadores de visibilidad que me permiten manejar la encapsulación. Así como una clase tiene funciones privada, protegidas y publicas, un namespace debería poder indicar que nombres se exportan y que nombres son internos al paquete.

PD: Desactualización de las IDEs

La lógica de resolución de nombres no es nada parecido a cuanto se viene haciendo en PHP. Las IDEs van a tener que actualizarse, y esta actualización no es coser y cantar.

Antigamente, os programadores tentavam resolver o conflito pré-fixando os nomes com algum tipo de qualificador. Essa solução não é boa porque não é escalável, os nomes tornam-se maiores e você gasta menos tempo escrevendo o software e mais tempo digitando e lendo e relendo nomes longos e incompreensíveis.

Para resolver este problema, tanto no .NET quanto no Java, podemos criar um "contêiner" nomeado, desta forma duas classes com o mesmo nome não serão confundidas entre si se elas estiverem em "contêiners" diferentes. É uma boa prática definir todas as suas classes em "contêiners".

Os contêiners podem ser utilizados tanto no .NET quanto no Java, no .NET chamamos de "namespaces" e no Java chamamos de "packages" (pacotes).

Conceitualmente não existem diferenças entre as duas linguagens, porém, sintaticamente existem diferenças, mas nada que não seja de fácil assimilação. Veja:

• Em Java, um package representa fisicamente uma pasta (ou diretório para os puristas);
• Em .NET um namespace não está relacionado a uma pasta. É possível ter uma pasta com um nome e dentro desta pasta, classes que pertençam a um namespace com outro nome, ou ainda, em uma pasta é possível existirem classes com namespaces diferente.  

Exemplo .NET:

namespace Financeiro
{
     class Calculo
     {
           ......
     }
}

namespace Estoque
{
     class Calculo
     {
           ......
     }
}

Exemplo Java:

package br.com.meusistema.financeiro;
public class calculo {
     .......
}

package br.com.meusistema.estoque;
public class calculo {
     .......
}

Nos dois exemplos acima (.NET e Java), conseguimos ter duas classes com o mesmo nome, porém em contêiners diferentes dentro do mesmo sistema.

.NET
     Financeiro.calculo
     Estoque.calculo

Java
    br.com.meusistema.financeiro.calculo
    br.com.meusistema.estoque.calculo

..:: Whereever you go, stay in touch. Download toolbar now! It´s free, private and secure. ::..

today's article is about adding namespaces to your XML document using Java and Dom4j, so let's get started...

First of all we need an instance of the Dom4j factory, here is how we do it...

//Get an instance of the dom4j document factory
DocumentFactory factory = DocumentFactory.getInstance();

...next we create an element which is going to serve as the root element as well as a new xml document using the factory object.

//use the factory to create a root element
Element rootElement = factory.createElement("RootElement");
//use the factory to create a new document with the previously created root element
Document doc = factory.createDocument(rootElement);

Now we are ready to create our namespaces.

//create some dom4j namespaces that we like to add to our new document
Namespace namespace1 = new Namespace("xsd","http://www.w3.org/2001/XMLSchema#");
Namespace namespace2 = new Namespace("rdfs","http://www.w3.org/2000/01/rdf-schema#");
Namespace namespace3 = new Namespace("rdf","http://www.w3.org/1999/02/22-rdf-syntax-ns#");
Namespace namespace4 = new Namespace("owl","http://www.w3.org/2002/07/owl#");
Namespace namespace5 = new Namespace("some","http://some/other/namespace:-)#");

The last step we have to take is to add all the namespaces to the XML document.

//add the created namespaces to the document
doc.getRootElement().add(namespace1);
doc.getRootElement().add(namespace2);
doc.getRootElement().add(namespace3);
doc.getRootElement().add(namespace4);
doc.getRootElement().add(namespace5);

Finished! To check if everything worked as intended we're going to write the document to an XML file...

try {
//write the created document to an arbitrary file
FileOutputStream fos = new FileOutputStream( "files/output.xml" );

OutputFormat outformat = OutputFormat.createPrettyPrint();
XMLWriter writer = new XMLWriter(fos, outformat);
writer.write(doc);
writer.flush();

} catch (FileNotFoundException e) {
// catch exception
e.printStackTrace();
} catch (UnsupportedEncodingException e) {
// catch exception
e.printStackTrace();
} catch (IOException e) {
// catch exception
e.printStackTrace();
}

...if everything went fine we should end up with an XML file that looks like this:

<?xml version="1.0" encoding="UTF-8"?>

<RootElement xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:some="http://some/other/namespace:-)#">

</RootElement>

So this is how you add namespaces to your xml document via Dom4j...have a nice day and stay tuned for more face-melting articles :o)...

A Shell Namespace Extension that creates a virtual filesystem around your Google GMail account
GMail Drive is a Shell Namespace Extension that creates a virtual filesystem around your Google GMail account, allowing you to use GMail as a storage medium.

GMail Drive creates a virtual filesystem on top of your Google GMail account and enables you to save and retrieve files stored on your GMail account directly from inside Windows Explorer.

GMail Drive literally adds a new drive to your computer under the My Computer folder, where you can create new folders, copy and drag’n'drop files to.GMail Drive shell extension is a tool that creates a virtual filesystem.

Ever since Google started to offer users a GMail e-mail account, which includes storage space of a 1000 megabytes, you have had
plenty of storage space but not a lot to fill it up with.

With GMail Drive you can easily copy files to your GMail account and retrieve them again. When you create a new file using GMail Drive, it generates an e-mail and posts it to your account.

The e-mail appears in your normal Inbox folder, and the file is attached as an e-mail attachment. GMail Drive periodically checks your mail account (using the GMail search function) to see if new files have arrived and to rebuild the directory structures.

But basically GMail Drive acts as any other hard-drive installed on your computer.
You can copy files to and from the GMail Drive folder simply by using drag’n'drop like you’re used to with the normal Explorer folders.

Because the GMail files will clutter up your Inbox folder, you may wish to create a **** in GMail to automatically move the files (prefixed with the GMAILFS letters) to your archived mail folder.

Please note that GMail Drive is still an experimental tool. There’s still a number of limitations of the file-system (such as total filename size must be less than 40 characters), and it doesn’t make full use of the secure internet protocols available.

You can try Xmail alternative for portability.

Requirements:

· Internet Explorer 5 or better

Go back to home page

<UserControl xmlns="http://schemas.microsoft.com/client/2007"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

In Beta 2 the default namespace has changed :

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

The change has more than likely occurred as part of the work to make the Silverlight 2 API more compatible with WPF, although WPF 3.5 does define a new XML namespace :

xmlns="http://schemas.microsoft.com/netfx/2007/xaml/presentation"

Compatibility should still be maintained however as this namespace or the namespace defined in WPF 3.0 can be used when building WPF 3.5 applications.

XML Namespaces

An XML namespace must be a valid Uniform Resource Identifier (URI), a URI can either be a Uniform Resource Locator (URL) as in the above examples or a Uniform Resource Name (URN) as in the example below :

xmlns:charts="clr-namespace:Charts;assembly=Charts"

These URI's do not resolve to any useful resource if you put them in the address bar in Internet Explorer for example, their only job is to be unique.  A common way to guarantee that uniqueness throughout the XAML's travels is to start by using a domain name previously registered with an Internet Naming Authority such as schemas.microsoft.com and add a custom suffix such as netfx/2007/xaml/presentation.

The Default Namespace

There can be only one default XML namespace for an element, any additional namespaces must use a prefix.  In the default XAML markup below, the URI specified by the xmlns identifier without any prefix is the default namespace for the UserControl element and it's descendant elements (the namespace's scope) but default namespaces have no affect on attributes.  This means that all unqualified element names within the default namespace's scope (UserControl and Grid) are implicitly associated with that namespace's URI.

<UserControl x:Class="SilverlightApplication1.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">

    </Grid>
</UserControl>

This is important because it is this implicit namespace URI that the XAML processor uses to search referenced assemblies to find the matching CLR Type for these unqualified elements.  The image below shows the default references for a standard Silverlight Application containing the above markup :

These referenced assemblies are searched by the XAML processor for a predefined, hardcoded attribute (the XmlnsDefinition attribute) defining this implicit URI as it's 'key' :

When found, as many are in the System.Windows.dll assembly only, the name of a CLR namespace is retrieved from the 'value' of the same attribute.  This CLR namespace is then returned as a scope for the XAML processor to search within to find the matching CLR Type for the XAML element.  Both the UserControl and the Grid types are found in the System.Windows.Controls CLR namespace in this way :

You can see from the illustration above that twelve CLR namespaces in the System.Windows.dll assembly are mapped to the Silverlight Beta 2 default XAML namespace and that the Beta 1 namespace is currently still supported.  Note that this process is also the method by which the CLR Application type, instantiated by the the Silverlight plug-in control, is mapped :

<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             x:Class="SilverlightApplication1.App"
             >

</Application>

Using the default XML namespace on the Application element in App.xaml, this fundamental CLR type is found in the System.Windows namespace again in the System.Windows.dll assembly :

Prefixed Namespaces

To recap, there can be only one default XML namespace for an element, any additional namespaces must use a prefix and default namespaces have no affect on attributes.  In order to affect an attribute with a namespace a prefix must be used, the prefix then becomes an abbreviation for that namespace.  In this way the x prefix is used by convention with it's corresponding pre-defined URI to fulfil Silverlight's contract as an implementation of the XAML language :

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

The XAML language expects implementers of it's syntax to expose certain fundamental attributes such as x:Class and x:Name (as show in the examples above) so the processor can perform duties such as joining a code-behind file to a XAML file through a partial class and creating members of that class with meaningful names.  This functionality is manifest in the System.Windows.Markup namespace also in the System.Windows.dll assembly.

For more information on XML namespaces in general and how they affect the family of XML technologies, have a look here and here.

[sourcecode language='cpp']namespace tr1=std::tr1; // New name will be tr1
using namespace tr1; // Using this new name[/sourcecode]

You can create xml:base atribute in this way:

XElement myEl = new XElement("Root",
new XAttribute(XNamespace.XML+"base", "attributeValue")
);

The result is:

<Root xml:base="attributeValue"/>

Proprio gli sviluppatori saranno felici di apprendere che nella prossima major release di PHP troveranno spazio numerose, gustose novità. Volete qualche anticipazione? Miglior supporto alla codifica Unicode, introduzione dei namespace, integrazione con SOAP e, sul fronte della sicurezza, rimozione di register_globals, magic quotes e safe mode.

Informazioni più dettagliate sulle novità di PHP6 sono disponibili sulle pagine di IBM DeveloperWorks.

[via: ossblog.it]

Even though everything seemed to fit, we got an error message back from the service:

After digging around on a number of blogs, forums and Information Centers, we found the issue: The WS-Addressing namespace. WSE 3.0 sets the WSA-ns to:
http://schemas.xmlsoap.org/ws/2004/08/addressing

while WMB 6.1 uses:
http://www.w3.org/2005/08/addressing

Since the WS-Addressing feature cannot be configured we decided to contact the developer of the web service to see if he can change the namespace (or perhaps remove WSA altogether). As a last resort we'd probably have to download Axis (which is used by WMB when communicating with web services) and change the namespace constant. An update is soon to come..