anyType encoder with xsi type

[rauanmayemir]

Support Question

I tried to follow the examples and set up custom anyType encoder that could inject 'non-string' XML.

$registry->addSimpleTypeConverter(
    namespace: Xmlns::xsd()->value(),
    name: 'anyType',
    encoder: new AnyTypeEncoder(new MyObjectTypeEncoder()),
);

AnyTypeEncoder is pretty much a proxy into MyObjectTypeEncoder:

/**
 * @template T of GetMyObjectRequestType|GetMyObjectResponseType
 * @implements XmlEncoder<T, string>
 */
final class MyObjectTypeEncoder implements XmlEncoder, XsiTypeCalculator
{
    private SerializerInterface $serializer;

    public function __construct()
    {
        $this->serializer = MyObjectSerializerFactory::createSerializer();
    }

    /**
     * @return Iso<T, string>
     */
    public function iso(Context $context): Iso
    {
        return new Iso(
            fn(mixed $data): string => $this->to($context, $data),
            fn(string $data): mixed => match ($context->type->getName()) {
                GetMyObjectRequestType::class => $this->serializer->deserialize($data, GetMyObjectRequestType::class, 'xml'),
                GetMyObjectResponseType::class => $this->serializer->deserialize($data, GetMyObjectResponseType::class, 'xml'),
                default => throw RestrictionException::unsupportedValueType($context->type, $data),
            },
        );
    }

    /**
     * @param T $data
     * @return non-empty-string
     */
    private function to(Context $context, mixed $data): string
    {
        $wrapped = $this->serializer->serialize(
            data: $data,
            format: 'xml',
        );

        return str_replace(['<result>', '</result>'], '', trim_xml_header($wrapped));
    }

    public function resolveXsiTypeForValue(Context $context, mixed $value): string
    {
        return match (true) {
            $value instanceof GetMyObjectRequestType => 'getMyObjectRequestType',
            $value instanceof GetMyObjectResponseType => 'getMyObjectResponseType',
            default => ElementValueBuilder::resolveXsiTypeForValue($context, $value),
        };
    }

    public function shouldIncludeXsiTargetNamespace(Context $context): bool
    {
        return true;
    }
}

My first problem is that the resulting output is escaped and looks like this:

<data xsi:type="getMyObjectRequestType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  &lt;ns-001db19f:field1 xmlns:ns-001db19f=&quot;http://example.com/ns/my/object&quot;&gt;value1&lt;/ns-001db19f:field1&gt;
  &lt;ns-001db19f:field2 xmlns:ns-001db19f=&quot;http://example.com/ns/my/object&quot;&gt;value2&lt;/ns-001db19f:field2&gt;
  &lt;ns-001db19f:field3 xmlns:ns-001db19f=&quot;http://example.com/ns/my/object&quot;&gt;value3&lt;/ns-001db19f:field3&gt;
</data>

whereas I want it to be a proper XML:

<data xsi:type="getUserDataRequestType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <ns-001db19f:field1 xmlns:ns-001db19f="http://example.com/ns/my/object">value1</ns-001db19f:field1>
  <ns-001db19f:field2 xmlns:ns-001db19f="http://example.com/ns/my/object">value2</ns-001db19f:field2>
  <ns-001db19f:field3 xmlns:ns-001db19f="http://example.com/ns/my/object">value3</ns-001db19f:field3>
</data>

My second problem is that I'm using a JMS Serializer for an XSD schema that only defines types, i.e the there are no elements, so my serializer have not types with xml_root_name. Because of that serialized output will wrap the XML with <result> root.

What would be my best course of action to fake a root object that could be recognized as anyType mixed element?

On ext-soap-engine, I used to hack the input by wrapping it like $data = new \SoapVar(trim_xml_header($xml), XSD_ANYXML);.

While writing this, I realized that the xsd type was supposed to be anyxml. But from what I've seen in the wild, anyType should also support non-escaped output when xsi:type is explicitly not a string.

[veewee]

Hello @rauanmayemir,

In this repo (currently) the simpleType encoders don't have durect access to the element that is containing it.
That is because a simple type could either be used as an element value or in an attribute value and is therefore considered simple.

Frequently, those kind of free-XML types are being wrapped with a complexType. If that's that case for your schema, it is possible to add a complexType encoder similar to the one in this example:
https://github.com/php-soap/encoding/blob/main/examples/encoders/complexType/any-elements.php

If not, it could make sense to introduce a new Feature interface that dictates the system that it can deal as an XML element so that it doesn't have to wrap the built-in ElementEncoder. That would give you full access to reading and writing the XML. (cause now you have access to nodeValue - which strips away the inner XML items. Meaning your deserializer won't work.

It will come with some complexities though : What if the anyType you are encoding is actually an attribute? That's then a case you'dd need to keep in mind as an end user. Also the XSI type part would then be built-in into your custom encoder directly as an XML attribute (without the XsiTypeCalculator feature).

I think it makes sense to introduce this feature nevertheless, since it gives you full control. What would your preference be?

[rauanmayemir]

Regarding the quotation of XML tags in the output, I traced it to the ElementValueBuilder.
I think creating a new Soap\Encoding\Encoder\Feature\Raw interface could hint the builder to use raw($encoded) instead of value($encoded).

[rauanmayemir]

I might have been chasing the wrong angle with wrapping a simple type encoder for anyType, however, it seems like the best approach as it supports using XSI 'type-hinting'.

I looked into using complex type encoders, and they feel a bit hacky as they inject content in a way that's truly raw. So XSI features allowing to inject anyType as a typed part look more natural to me.

[veewee]

Both the ElementValueBuilder and the ElementValueReader are not created to support this Raw purpose.
In that case, I think it would make more sense to skip the ElementEncoder completely and make it possible to build the raw XML from within your encoder instead. (since you already have it).

Injecting raw xml into the parent is basically how the complete system works : every encoder provides raw xml to the wrapped encoder. It's not hacky as long as the encoders make sure that the XML rules are being applied correctly.

That way you could use it like so:

EncoderRegistry::default()
    ->addSimpleTypeConverter(
        namespace: Xmlns::xsd()->value(),
        name: 'anyType',
        encoder: new class implements XmlEncoder /**NEW: Feature/ElementProvidingEncoder*/ {
            /**
             * @return Iso<array, string>
             */
            public function iso(Context $context): Iso
            {
                if ($context->type->getMeta()->isAttribute()->unwrapOr(false)) {
                    return new ScalarTypeEncoder();
                }

                $typeName = $context->type->getName();

                return new Iso(
                    to: static fn (array $data): string => document_encode([$typeName => $data])
                        ->manipulate(fn (\DOMDocument $document) => $document->documentElement->setAttribute('xsi:type', '....'))
                        ->stringifyDocumentElement(),
                    from: static fn (Element|string $xml): array => xml_decode(
                        // You could use xsi:type from element to determine target class type.
                        ($xml instanceof Element ? $xml : Element::fromString($xml))->value()
                    )[$typeName],
                );
            }
        }
    );

(instead of JMS serializer, this one uses veewee/xml, but the same is true for JMS serializer and you could easily change your code to make it work like this)

The result looks like this:

 <customerData> <!-- anytype -->
   <foo />
   <bar />
   <hello>world</hello>
 </customerData>

  ^ {#1761
   +"customerName": "John Doe"
   +"customerEmail": "john@doe.com"
   +"customerData": array:3 [
     "foo" => ""
     "bar" => ""
     "hello" => "world"
   ]
 }
```

[rauanmayemir]

What you suggested looks great. This is indeed perfect for cases when the WSDL makes the service as generic as it gets, so anyType payload is expected to use its own schema/serialization.