Styler and namespaces?

[ptc-953343]

We have been building a DTD and editing environment with a DTD that
used a namespace for a few elements in the body of the DTD. This
namespace was given a prefix and those prefixes show up in Styler and Epic.

We want to change this design and put the namespace at the top of the
DTD such that all the elements are in our namespace. Our first try
was to use a default namespace (no prefix value).

We are seeing some things I don't understand in styler and possibly
Epic. First when we load the existing application up it looks like
all the elements are styled properly and Epic just lists the names.
When we import elements into styler from this new environment I get
names now with a "_:" in front which I assume is the indication that
these are in a default namespace.

First I would have thought Epic and Styler would show these names consistently.

Second, why are we still getting the correct styling for the document
when my elements are essentially new?

We have a Java customization that is inserting an element from the no
namespace environment and it adds a xmlns=" via the editor (our code
is not doing this, the Editor is). If I add our namespace value it
shows as a good element (rather than in red with the lines through
the tags) , but now it is flagged as unstyled?

Does this make sense? Our stylesheet seems to be working without
reference to the namespace but that doesn't seem correct. We can live
with this but I'm wondering about content that is supposed to
reference other element content - how should those references be created?

Any advice is welcome.

thanks

...dan

[EmanuelW]

Hello Dan!



We were experiencing the same issue when updating from DTD-based stuff to XSD with Namespaces. Copying over our old stylesheets, it somewhat worked. Somewhat.

The first thing to notice, Synchronization between the Editor view and the Styler contexts does not work - which is correct, considering that <para> and <{someNamespace}:para> are not the same elements. However, styling did work.

The second thing which made quite some problems there, we are using kind of compound construct that includes other doctypes using XInclude, and of course also uses parts of their stylesheets in a compound stylesheet. Namespaces broke that, as (like above mentioned) <{nameSpace1}:para> is not the same as <{nameSpace2}:para>. As this one is generated, and only for publishing, we decided to run an XSLT before publishing that removed all Namespaces but the root-one.



Looking at other people that use this techniques, we saw that the folks over at the AECMA (Specification 1000D, for those who ever heard of it) were using noNamespaceSchemaLocation instead. And in-fact, this works like the DTD ones, even with compund ones.

So I'd recommend switching over to noNamespaceSchemaLocation if there are no other limitations that require Namespaces.



You should also note that we experienced bigger problems with that before when upgrading from 5.2 M040 to 5.3 because they appearently "fixed" Namespace handling - which pretty broke above workaround. We did switch over to noNamespaceSchemaLocation already, but for some older legacy stuff, we still have to support the ones with xmlns. For those stylesheets, we had to change attribute matching and certain contexts to use local-name() rather than the node-name itself.



I hope this helps on your problem.



Greetings, Wlaschitz Emanuel

[ptc-953343]

thanks for the confirmation that we didn't do something wrong. Its
disappointing that Styler doesn't work properly. We probably won't
move forward with this as we don't want to risk something breaking
and having to un-do the work.

..dan