Introduction

If a person's real surname is "Null", the challenge is making sure your ActionScript code sends the literal string "Null" instead of a missing value. In SOAP, that distinction matters because an actual null is usually represented differently from a normal string, often through an omitted element or an xsi:nil attribute.

So the main rule is simple: if the surname is literally the word Null, send it as a string value in the SOAP body. Do not let your client code or serializer treat it as the programming value null.

Understand The Difference Between null And "Null"

In ActionScript:

• 'null means no object reference'
• '"Null" is a string containing four characters'

SOAP serializers care about that difference too. A normal string element looks like:

<Surname>Null</Surname>

A true null value is typically represented more like:

<Surname xsi:nil="true" />

Those are not interchangeable. If the surname is a real family name, you want the first form.

Pass The Value As A String

If you are building the request manually, the simplest fix is to ensure the field is typed and stored as a string:

1var surname:String = "Null";
2
3var soapBody:XML =
4    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
5        <soap:Body>
6            <ns:SubmitPerson xmlns:ns="http://example.com/">
7                <ns:Surname>{surname}</ns:Surname>
8            </ns:SubmitPerson>
9        </soap:Body>
10    </soap:Envelope>;
11
12trace(soapBody);

Because surname is a string, the XML serializer will emit the literal text content Null, not an empty or nil element.

Be Careful With Generated SOAP Clients

If you are using a generated AS3 SOAP client or a wrapper object, the bug can happen one layer earlier. For example, some code maps empty or special input values before serialization. If a helper function turns "Null" into null, the outgoing SOAP request becomes semantically wrong even though your UI field looked correct.

A safer pattern is to keep the domain model typed explicitly:

1public class PersonRequest {
2    public var surname:String;
3}
4
5var request:PersonRequest = new PersonRequest();
6request.surname = "Null";

Then inspect the actual outgoing SOAP envelope rather than assuming the serializer preserved the value.

Inspect The Wire Format

When debugging SOAP problems like this, the fastest truth source is the XML that actually leaves the client. If the envelope contains:

<Surname>Null</Surname>

then the client sent the correct literal string. If the envelope contains an omitted node or xsi:nil="true", the problem happened before the server ever saw the value.

That is why logging or capturing the outgoing request is so useful. It lets you separate client-side serialization mistakes from server-side interpretation issues.

When You Really Do Need A Null Value

Sometimes the same field needs to support both meanings:

• literal surname "Null"
• actual missing surname

In that case, the API contract must distinguish them clearly. The literal surname should be sent as text. A true missing value should be sent as null according to the SOAP schema, often using xsi:nil="true" if the element is nillable.

That distinction is not a weird edge case. It is exactly why schemas differentiate string values from nil values in the first place.

Common Pitfalls

One common mistake is assuming the word "Null" is dangerous by itself. It is only dangerous if your code converts it into the actual programming value null. Another is debugging the server before inspecting the outgoing SOAP envelope. Developers also sometimes trim, sanitize, or "normalize" input with helper logic that accidentally rewrites real string values. Finally, if the WSDL marks the field as nillable, that does not mean every occurrence of the text Null should become nil. It only means the field is allowed to be nil when the application explicitly chooses that.

Summary

• The literal surname "Null" should be sent as a normal string value in the SOAP body.
• Do not let ActionScript or your serializer convert "Null" into the programming value null.
• Inspect the actual outgoing XML to confirm whether the client sent text or xsi:nil.
• Use xsi:nil only when the value is truly missing, not when the surname really is Null.
• Keep the client model typed clearly so special string values are not accidentally normalized away.