Raw Field binding not working as expected

[PuglyD]

Ive been trying out this package for a couple of days now, I have some XML files at work that I need to handle in a more python native way. One section of the XML looks something like this:

<Section>
      <Value1>
           <Address></Address>
      </Value1>
      <Value2>
           <Address></Address>
       </Value2>
      <Value3>
           <Address></Address>
      </Value3>
</Section>

I tried defining a model with raw elements, as detailed in the docs, the next step would've been creating a model from each element, but I first wanted to see if the parser managed to find these elements and it didn't. Here's my example code:

from typing import List
from lxml import etree
from lxml.etree import _Element as Element
from pydantic-xml import BaseXmlModel, element
from pydantic import ConfigDict


class Section(BaseXmlModel, tag='Section'):
    model_config = ConfigDict(arbitrary_types_allowed=True)
    raw: List[Element] = element(tag='*', exclude=True, default=[])
    
xml = """
<Section>
      <Value1>
           <Address></Address>
      </Value1>
      <Value2>
           <Address></Address>
       </Value2>
      <Value3>
           <Address></Address>
      </Value3>
</Section>
"""

root = etree.fromstring(xml)

model = Section.from_xml_tree(root)

print(len(model.raw))

Instead of the wildcard, I tried using all sorts of patterns, weird thing is, if i write the name of the first element it matches, but any other element it doesnt. meaning if i change tag to Value1 it matches but Value2 doesnt. Furthermore if I change all of the tags to the same name then it returns the full list.

Anybody have any idea? Would really appreciate any help, thank you!

Python version v3.12.4
Pydantic version v2.12.2
Pydantic-xml version v2.18.0

[dapper91]

@PuglyD Hi,

element tag doesn't support wildcards, it must be an explicit tag name

[PuglyD]

Hey @dapper91 , thanks for clarifying!

I'm having a hard time understanding how I would handle such data, Needs to support N nested sections, or is it a known limitation? Do you have any ideas of how I could tackle this?

Are pattern matches planned anytime in the future?