Alex Rivera | Logout

Is it appropriate to use non-ASCII (natural-language) XML tags?

Asked 2010-05-20T11:31:20.160
9

Is it appropriate to use XML tags (element names) written in non-ASCII natural languages? The XML spec allows it (see Names and Exceptions), but I couldn't find any best practices about this at W3C and related pages.

What I'm looking for is practical advice regarding which tools support this, whether important XML-related technologies such as XSLT and XForms may have problems with it, etc.

I think Andrey and Tomalak are missing the point. XML is not necessarily read by programmers, it is read by many different professionals. So the arguments comparing it to source code don't necessarily apply.

Let me clarify: I mean a Bulgarian legal domain, where many terms are specific to the Bulgarian legal process, and may not even have exact English translations. Translating them would be laborious, imprecise and impractical. Transliterating to ASCII is suboptimal.

So back to the question: what tool limitations would I face? (Eclipse supports UTF, so writing xpaths wouldn't be a problem.)

To get people started in the technical direction that I'd like: in several systems we've used generation techniques to ensure perfect correspondence between XML schemas, Java beans and database schemas.

  • Java: this article says that Unicode is ok
  • Oracle: identifiers can contain only alphanumeric characters from your database character set
  • I'd have to check for the tooling we use (JibX, Dozer, Hibernate, JXPath...)
    Edit
    Report

1 Answer

1

I'm sorry to say this, but if your non-technical users needs to read raw XML, your application is broken. And the data you store will not usually have a 1-1 correspondence with user messages, either: many things are stored in a redundant way on XML, and other things are implicit from the data.

For me, I think you should, yes, store all your XML data in Bulgarian, using the UTF-8 character set. But in attributes, not in the XML tag structure.

I am thinking on this: you could design your program so that any of the legal structure can be modified freely from the user interface (maybe on a special "admin" panel, but still far from the code), and in no way hard-coded to the file format. The reason for this is that laws change, jurisprudence change and legal terms may change as well. (Well, some don't)

This may enable you to create a fairly general file format (think about one that could be used on US or japan, too - even if you don't plan to actually do it, that way your changes of designing a flexible file format will be greater)

This may be harder. You need to be prepared to handle with inconsistent, incomplete or otherwise poor data. But you should be doing this, anyway. And you may be rewarded, too: the file format could be cleaner and future-proof, making your software more flexible. Or maybe not. Notice the mays, coulds here. It actually depends on your specific design trade-offs.

And, of course, you need to have some balance here. In the end of the day, the burden of designing a reliable, flexible system is on you. You may take the approach of writing the tags in Bulgarian. I'm from Brazil, and I find odd to think about something like , but it could work.

About your actual concerns on tool limitations: I have no idea. You should first look for the documentation of you favorite XML library and see if it boldly claims to support it. Even the most used programs may not support fully a feature that is not much used.

answered 2010-05-24T04:09:13.157

Your Answer