Symphony.

Ok, so here is the deal:

I am currently looking into well-formed XSL and the correct use of namespaces. Since we are (mostly) generating (x)HTML(5) with our XSL-templates, the proper namespace to use for HTML is http://www.w3.org/1999/xhtml. This goes for XHTML and for HTML5.

Now I noticed that the XSLT-parser automaticly adds this namespace to the HTML-code when you're not applying any namespace to your XSL stylesheet. But for well-formed XSL this namespace should be added to your XSL-stylesheet as well. Your XSLT-processor should know what kind of contents it's dealing with. For example, if you would generate a Google XML sitemap, your document should have the namespace http://www.sitemaps.org/schemas/sitemap/0.9, or if you wish to create an Atom- or RSS-feed you should use a namespace for this. Also, most IDE's for writing code don't give HTML code completion for XSL-stylesheets, but look at the namespaces used for the document to provide proper code completion and live syntax checking (JetBrains PHPStorm does this for example).

Now here comes the funny part: the XML provided by Symphony is provided as good old plain XML, without any namespace. This means that if you have something like:

<content mode="formatted">
    <h1>Header</h1>
    <p>Some content</p>
</content>

The XSLT-parser wouldn't 'recognize' it as HTML, but simply as XML-tags which happen to have the same element name as our well-beloved HTML-tags. So if I would do something like:

<xsl:copy-of select="content/*" />

...which is widely used by almost everybody, the XSLT-parser would add a xmlns=""-namespace to each top-indexed HTML element because it thinks: "Hey! The nodes that are imported are from a different kind if namespace than the target I am copying them to! I'dd best copy their namespace too, so the final destination where I'm sending my transformed XML to knows what to do with it!".

Something like this could be solved by using xsl:apply-templates together with some XSLT-ninja-utility:

<xsl:apply-templates select="content/*" mode="html" />

...but wouldn't it be better if the correct namespace is added in the XML that Symphony outputs? So the XML should be:

<content mode="formatted" xmlns="http://www.w3.org/1999/xhtml">
    <h1>Header</h1>
    <p>Some content</p>
</content>

This sounds logical, because then you have a section inside your 'plain old XML' which says: "Hey you guys! My content is HTML!"

I would realy like to here some reactions/thoughts on this, because I'm trying to 'understand' namespaces, write correct XSL and try to pay some attention to how Symphony 'ticks' in these cases; I mean, when importing an external datasource, you are also asked to supply some namespaces, so why is HTML outputted with no namespace at all?

Yes, in theory I agree. In theory, communism works, in theory.

But this gets tricky. Right now its kind of implied that any markup you store in a field is xhtml. If you are storing other flavors of xml, you usually have to give that its own ns declaration in the content, which is a little messy. What exactly do you suggest? Should namespaces be assigned per field? or per datasource? I can see being able to check a box on a textarea to give it an html namespace.

Things could also get very interesting if you were to namespace whole datasources and/or sections. This could lead to writing more generic XSLT that could be applied in more contexts. For instance, imagine a 'listing' datasource namespace, which just lists the title fields of a section. You could potentially write xslt that could match on the namespace rather than the actual fields, and use that xslt any time you wanted to list a section's entries. Basically writing namespace-rich xslt would be where the rubber hits the road if Symphony were to become a Semantic CMS.

Anyway, I think namespaced html was an intentional omission in order to let new users get into xslt and Symphony without going completely insane, but I see no reason not to have the choice.

I vote for whatever is simplest. Aschooner is right that that new users don't want to deal with this kind of complexity. Symphony is already hard enough to learn.

In my opinion there is nothing wrong when using plain old XML as long as you use xsl:value-of; after all, that's what XML is ment for in this case: to store textual information. But as soon as you start storing HTML in your XML file and start using xsl:copy-of to retrieve your content, then namespaces should be there (in a perfect, symantic world).

So what I think: If the output of a field is HTML, the XML-element used to store that HTML-content should have the proper namespace. I did some testing with this however, but when I modify field.textarea.php and add the namespace as an attribute, then the xsl:copy-of-command returns nothing.

@kanduvisla

Is the ns declaration loading successfully into the datasource output xml? If so, can you post your xml/xslt?