From the documentation and functions, the following lines conflict with one another:
```racket
(can-be-txexpr-attr-value? 'symbol)
#t
(can-be-txexpr-attrs? '((foo bar)))
#f
(can-be-txexpr-attrs? '((foo "bar")))
#t
```
At some point it seems that symbols were set to be invalid (or were always supposed to be invalid) attribute values.
```racket
(validate-txexpr '(tx ((foo bar)) baz (p bin)))
validate-txexpr: attribute value is not a string
attribute value: 'bar
in: '(tx ((foo bar)) baz (p bin))
(validate-txexpr '(tx ((foo "bar")) baz (p bin)))
'(tx ((foo "bar")) baz (p bin))
(attr-join '(tx ((foo "bar")) baz (p bin)) 'key 'val)
string-join: contract violation
expected: (listof string?)
given: '(val)
```
It seems like much of the goal of the package is to have interoperability with XML via xexpr->string and so on, which will fail if a txexpr-attr-value has anything other than a string. The easiest change would be to make (can-be-txexpr-attr-value? 'symbol) return #f.
It seems like much of the goal of the package is to have interoperability with XML via `xexpr->string` and so on, which will fail if a txexpr-attr-value has anything other than a string. The easiest change would be to make `(can-be-txexpr-attr-value? 'symbol)` return `#f`.
On closer inspection, I don’t consider this a bug. There is a difference between the predicate txexpr-attr-value? (which indeed rejects symbols) and can-be-txexpr-attr-value? which, as the name suggests, represents things that can be losslessly converted to Racket strings. Including symbols.
The point of the distinction is to use the more lenient predicate (can-be-txexpr-attr-value?) on input values, and the stricter predicate (txexpr-attr-value?) on output.
On closer inspection, I don’t consider this a bug. There is a difference between the predicate `txexpr-attr-value?` (which indeed rejects symbols) and `can-be-txexpr-attr-value?` which, as the name suggests, represents things that can be losslessly converted to Racket strings. Including symbols.
The point of the distinction is to use the more lenient predicate (`can-be-txexpr-attr-value?`) on input values, and the stricter predicate (`txexpr-attr-value?`) on output.
From the documentation and functions, the following lines conflict with one another:
At some point it seems that symbols were set to be invalid (or were always supposed to be invalid) attribute values.
So which one needs to change for the results to make sense?
should be
#false
not#true
?It seems like much of the goal of the package is to have interoperability with XML via
xexpr->string
and so on, which will fail if a txexpr-attr-value has anything other than a string. The easiest change would be to make(can-be-txexpr-attr-value? 'symbol)
return#f
.On closer inspection, I don’t consider this a bug. There is a difference between the predicate
txexpr-attr-value?
(which indeed rejects symbols) andcan-be-txexpr-attr-value?
which, as the name suggests, represents things that can be losslessly converted to Racket strings. Including symbols.The point of the distinction is to use the more lenient predicate (
can-be-txexpr-attr-value?
) on input values, and the stricter predicate (txexpr-attr-value?
) on output.PS I do think your example
Should work, so I will fix that.