OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Enlightenment via avoiding the T-word



All,

While defenders of XML namespace mechanism might disagree, the mechanism is
controversial and troublesome for all parties (users, designers, etc.).
However, it is here and we must make the best of it by avoiding troublesome
areas.  Yes, our academic background drives us toward those troublesome
areas as flies, but practicality and common sense dictate that building on
shaky ground is not a good engineering practice.  XML Namespace is here to
stay and we, as XML experts, have to point out to people what area is safe
and what is not.

Labels or not, if these concepts have to be explained over and over, clarity
after long hours of deliberation and creative metaphors is not much of
clarity IMHO.  As the doctor said, stop doing it if it hurts you.

<my:person xmlns:my="http://example.com/my">
  <firstName>Chip</firstName>
  <lastName>Skillet</lastName>
</my:person>

Ambigous situations like above are best avoided rather than fixing already
shaky spec with further complication and special rules in the name of
clarity.  Programming languages like C and Java can be used to create
horrific code.  XML is no different.

My namespace rule (Simple Namespace Usage Guideline) is simple:

  no namespace prefix

Under this rule, above example is impossible.  Instead we would have:

<person xmlns="http://example.com/my.person">
  <firstName>Chip</firstName>
  <lastName>Skillet</lastName>
</person>

Situations my rule cannot cover are addressed by avoiding such sitations at
higher level.  Sometimes this is difficult, but far less difficult than
going the other way.

Best,

Don Park
Docuverse