[Xml-compile] NIL vs. undef?

[Mark Overmeer]

* Rob Coops (rcoops at gmail.com) [121024 07:57]:
> Though I agree with the fact that there is a difference on the XML level.
> For many applications though the difference between NIL, {} and undef is
> not all that relevant the end result for a display situation for instance
> is that there is no information to display in most cases. So for a person
> working on processing the XML it might very well be correct behavior to
> tread all 3 possibilities as undef.

That may be true for some application, yes.

The next rant is not personally ment against "E R": the following is
only to explain why I sometimes stubbornly refuse to make seemingly
simple changes...

There are many different components when an application talks to a
service provider.  XML::Compile's contribution is to map Perl to XML,
vice versa, based on a schema.  It tries to achieve a 100% perfect
mapping.  These are purely *formatting* issues.  There are enough
head-aches in that process, already.

In some other component, one will construct in- and out-going *information*.
Rebuilding the information in the main program (f.i. DB-info into XML-
structures and value representation conversions) If you decide that
'missing' and 'NIL' are the same information for your application,
that is your good right... to be implemented on this level.  This is
also the place to hide differences between versions of the protocol.

Again another component (or 'layer', if you want) is about modifying
information, moving it around.  The core application.

That's what I hate about XML-RPC: people forget the second component:
they mix the internal program interface with the external protocol. This
is extremely bad for developing a service over time.  I sleep better when
my stubborness forces people to implement that second layer, producing
maintainable code.

> I would not suggest that the Xml-compile solution does the translation to
> undef as that would remove valuable information but having the NIL object
> that does stringify to 'NIL' could be a nice meet in the middle type
> solution.

The consideration about such an object is only to be able to distiguish
between a string contents "NIL" and the attribute xsi:nil.  I do not
see that fulfil the requested "map nil onto undef".

> To facilitate the transition from the current way of working to the object
> a extra parameter could be provided to Xml-compile, upon the instance being
> created, telling it to use the original behavior if the parameter is set.

You hit my worries precisely on the head.  The default behavior for any
new implementation should be to use the new NIL object.  But existing
applications do not have a 'use_old_style_nil => 1' in their compile-
options...  If the new style is not the default, then it will never
get used: most people do not read the manual page carefully enough.

In general, I am not too afraid changing internals: when the 3500
regression tests pass, it will probably work for everyone.  However,
in this case, new overloaded objects will enter the user's programs.
Introducing overloading causes serious head-aches to Perl programs.
We need overloading because when cannot bless the string "NIL", but
only references... :(

Another solution may be to be able to hook into 'NIL'.  Hooks (and
typemaps) can help with formatting information.

> It is not pretty but it allows existing code to continue working while
> practically forcing new code to use the NIL object instead. Maybe looking
> at the context would be possible but I fear that many times this will lead
> to returning exactly the "wrong" response.

Gladly, the context is described in the schema, so well-defined.  The
lines of code where NIL is used for a complexType are clearly separated
from the lines where NIL is used for a simpleType or simpleContent.
-- 
Regards,

               MarkOv

------------------------------------------------------------------------
       Mark Overmeer MSc                                MARKOV Solutions
       Mark at Overmeer.net                          solutions at overmeer.net
http://Mark.Overmeer.net                   http://solutions.overmeer.net