bdarcus / csl-next-attic

a very tentative experiment ATM ...
2 stars 0 forks source link

Add extensible attribute values #19

Closed bdarcus closed 1 year ago

bdarcus commented 1 year ago

In CSL 1.0, we have lists of tokens, that are not extensible.

Here's another strategy:

https://www.w3.org/MarkUp/Forms/wiki/XForms-nons-20.rnc

Here they're allowing foreign namespace-prefix-like patterns in the attribute value.

(xsd:NMTOKEN - (xsd:NMTOKEN { pattern = "xforms-.*" }))

See xforms.ActionName.

So this schema has attribute values like xforms-value-changed, that they define in this schema.

They are thus core value tokens.

That pattern then allows other values like bar-test, but not, for example, just foo.

So it's a way to have constrained lists of values, but allow others.

We would want to dig into whether and how this helps their extensibility story/plan.

denismaier commented 1 year ago

Hmmm. That sounds neat. We could then say, add allow prefixed attributes to a given version of the schema, describe those attributes in a experimental section of the specification, and maybe remove or approve later. Right?

bdarcus commented 1 year ago

Yes, but also different communities could experiment with stuff independently.

denismaier commented 1 year ago

Could that also work for conditionals?

bdarcus commented 1 year ago

I had been thinking of conditionals more from the standpoint of arbitrary-namespaced attributes, with the idea processors would ignore those nodes if they didn't understand them.

<if foo:bar="x">

But I didn't get far in terms of details; still just a vague idea.

bdarcus commented 1 year ago

A thought, related to the transforms idea.

One issue with XML is attributes are unordered; like a dictionary.

But piped filters rely on order.

So the (again vague ATM) idea:

Perhaps we could allow arbitrary namespaced attributes in places, but then lay out what they may do, when?