XML: Allow children of ElementSpec to also be ElementSpec #1590

Open
opened 2025-07-16 12:41:32 +02:00 by Mafus1 · 2 comments
Mafus1 commented 2025-07-16 12:41:32 +02:00 (Migrated from github.com)

I would like to provide auto complete for children of elements, where the name of the children is not unique.

In the example below, the elements infos are used for cars and bikes, but are completely different types of information. XSD allows this by specifying a type for an element as well as a name.

<car>
  <infos>
    <cc>3000</cc>
  </infos>
</car>
<bike>
  <infos>
    <gears>21</gears>
  </infos>
</bike>

Since I can only define an array of names as the children of ElementSpec, it is not possible to have a infos element that is different for cars vs. bikes.

I would suggest expanding the children property to be of type: (string | ElementSpec)[], or allow a child to be a reference to a type, not just a name.

Is that something you are willing to implement?

I would like to provide auto complete for children of elements, where the name of the children is not unique. In the example below, the elements `infos` are used for cars and bikes, but are completely different types of information. XSD allows this by specifying a type for an element as well as a name. ``` <car> <infos> <cc>3000</cc> </infos> </car> <bike> <infos> <gears>21</gears> </infos> </bike> ``` Since I can only define an array of names as the children of [ElementSpec](https://github.com/codemirror/lang-xml?tab=readme-ov-file#user-content-elementspec), it is not possible to have a `infos` element that is different for cars vs. bikes. I would suggest expanding the [children](https://github.com/codemirror/lang-xml?tab=readme-ov-file#user-content-elementspec.children) property to be of type: `(string | ElementSpec)[]`, or allow a child to be a reference to a type, not just a name. Is that something you are willing to implement?
marijnh commented 2025-07-18 08:29:25 +02:00 (Migrated from github.com)

When completing, the code currently only looks at the name of the surrounding element. To support what you're proposing, it'd have to trace the set of parents all the way from the root element to figure out what context it is in. This is possible but adds quite a bit of complexity and new failure modes (such as parent elements being missing of malformed). As such, I'm not sure this would be an improvement.

When completing, the code currently only looks at the name of the surrounding element. To support what you're proposing, it'd have to trace the set of parents all the way from the root element to figure out what context it is in. This is possible but adds quite a bit of complexity and new failure modes (such as parent elements being missing of malformed). As such, I'm not sure this would be an improvement.
Mafus1 commented 2025-07-21 08:23:41 +02:00 (Migrated from github.com)

I understand the complexity that this would add. But, I'm not sure how I would be able to support anything but the simplest schema with the current approach. Maybe I'm missing something? Do you have a suggestion how I could implement my example, besides changing the name of infos to car-infos and bike-infos or something similar?

I understand the complexity that this would add. But, I'm not sure how I would be able to support anything but the simplest schema with the current approach. Maybe I'm missing something? Do you have a suggestion how I could implement my example, besides changing the name of `infos` to `car-infos` and `bike-infos` or something similar?
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
codemirror/dev#1590
No description provided.