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: infinite depth to namespaces



Simon Said:
> Simple best-practice solutions are fairly easy to come up with, but
> seemingly just as easy to shoot down, suggesting that there may never be
> consensus on these issues.

I share your frustration Simon.  What we need is to give a clearly outlined
shape to the best-practice solutions for namespaces.  One can do a lot of
weird things with namespaces, but one must also have a good sense of what
the normal use of namespace is.  In mystic words, you must have a center
before you can have fringes.

Last year, I designed a payment authentication message format which used
XML-Signature.  Because some of the system component (provided by another
party) didn't have namespace support and because I wanted to minimal
namespace handling headaches, I made primary (payerauth) elements
namespace-less and required default namespace delcaration for XML-Signature
elements.  Result looked like this:

  <paymentResponse>
    ...
    <Signature xmlns="....">...</Signature>
  </paymentResponse>

Above message can be validated and processed without being aware of
namespaces, so I had achieved my goals regarding namespaces.  In retrospect,
I should have required use of default namespace declaration for primary
elements too so it would look like this:

  <paymentResponse xmlns="blahblah">
    ..
    <Signature xmlns="...">...</Signature>
  </paymentResponse>

This removes the need to understand namespace-less elements and prevents
'naive' architecture changes like making Signature elements namespace-less
also.  Alas, its too late since the spec went thru a major revision without
my participation.  Some valuable features like 'required Canonical XML use'
and 'formfeed document separator' were also removed.

Lessons I learned are:

1. be wary of introducing concepts that attract abuse
2. fully discuss and justify important features in the spec.

Default XML namespace concept is simple to understand, but 'no-namespace'
concept is even simpler and easy to abuse.  Unjustified features are like
trees with shallow roots.  Chances are they will get washed out in the next
storm if you are not there to hold them in place.

Best,

Don Park
Docuverse