Add option to dedent (only keep relative indentation) tag values

[bbb651]

I propose adding a new option to XMLParser, perhaps as an additional possible value for the already existing trimValues, to dedent (only keep relative indentation between lines, see dedent package and the String.dedent proposal) tag values.
Using indentation for tag values is very common in xml files, pretty much every multiline tag value (as in more than one line in the value itself, <tag>\n\tvalue\n</tag> happens to work with trimValues already) makes use of this.

My use case is parsing descriptions in wayland protocol xml files for https://wayland.app/. We are currently using tagValueProcessor to trim every line individually, but I'm working on parsing of nested markdown-like lists, for example in linux-dmabuf-unstable-v1.xml:

    <description summary="factory for creating dmabuf-based wl_buffers">
      Following the interfaces from:
      https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
      https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
      and the Linux DRM sub-system's AddFb2 ioctl.

      This interface offers ways to create generic dmabuf-based wl_buffers.

      Clients can use the get_surface_feedback request to get dmabuf feedback
      for a particular surface. If the client wants to retrieve feedback not
      tied to a surface, they can use the get_default_feedback request.

      The following are required from clients:

      - Clients must ensure that either all data in the dma-buf is
        coherent for all subsequent read access or that coherency is
        correctly handled by the underlying kernel-side dma-buf
        implementation.

      - Don't make any more attachments after sending the buffer to the
        compositor. Making more attachments later increases the risk of
        the compositor not being able to use (re-import) an existing
        dmabuf-based wl_buffer.

      The underlying graphics stack must ensure the following:

      - The dmabuf file descriptors relayed to the server will stay valid
        for the whole lifetime of the wl_buffer. This means the server may
        at any time use those fds to import the dmabuf into any kernel
        sub-system that might accept it.

      However, when the underlying graphics stack fails to deliver the
      promise, because of e.g. a device hot-unplug which raises internal
      errors, after the wl_buffer has been successfully created the
      compositor must not raise protocol errors to the client when dmabuf
      import later fails.

      To create a wl_buffer from one or more dmabufs, a client creates a
      zwp_linux_dmabuf_params_v1 object with a zwp_linux_dmabuf_v1.create_params
      request. All planes required by the intended format are added with
      the 'add' request. Finally, a 'create' or 'create_immed' request is
      issued, which has the following outcome depending on the import success.

      The 'create' request,
      - on success, triggers a 'created' event which provides the final
        wl_buffer to the client.
      - on failure, triggers a 'failed' event to convey that the server
        cannot use the dmabufs received from the client.

      For the 'create_immed' request,
      - on success, the server immediately imports the added dmabufs to
        create a wl_buffer. No event is sent from the server in this case.
      - on failure, the server can choose to either:
        - terminate the client by raising a fatal error.
        - mark the wl_buffer as failed, and send a 'failed' event to the
          client. If the client uses a failed wl_buffer as an argument to any
          request, the behaviour is compositor implementation-defined.

      For all DRM formats and unless specified in another protocol extension,
      pre-multiplied alpha is used for pixel values.

      Unless specified otherwise in another protocol extension, implicit
      synchronization is used. In other words, compositors and clients must
      wait and signal fences implicitly passed via the DMA-BUF's reservation
      mechanism.

      Disclaimer: This protocol extension has been marked stable. This copy is
      no longer used and only retained for backwards compatibility. The
      canonical version can be found in the stable/ directory.
    </description>

It's possible to workaround this with tagValueProcessor, but for how common and useful this is, and it being non-trivial to implement or requiring an additional dependency, I think it's worth having in fast-xml-parser (maybe as the default in a future breaking release? Although it does incur an additional performance cost). The implementation can also be switched to String.dedent transparently in the future when it's added and gets enough browser + node support.

[amitguptagwl]

I believe the issue is removing new line character. As I remember, I tried to handle it in v5. if not then can incorporate.

[bbb651]

I'm not sure what you mean, trimValues already removes unnecessary newlines, I'm talking about indentation i.e. spaces and tabs in the tag value itself

[amitguptagwl]

This is what I mean.

[amitguptagwl]

closing as no response. feel free to open it for any discussion