-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarify how syntactic shortcut for options are used with non-string option values #161
Comments
For a map, am I correct assuming you'd have to use an AVT in this case? <ex:stepType map-option="{map {
"Su" : "Sunday",
"Mo" : "Monday",
"Tu" : "Tuesday",
"We" : "Wednesday",
"Th" : "Thursday",
"Fr" : "Friday",
"Sa" : "Saturday"
}}"/> But for "castable" option value, e.g. <ex:stepType int-option="1"/> Or should it be interpreted as "a non-string value can only be set with AVT"? |
You're right, some clarity is required. I think there are two possibilities.
I have a slight preference for the former, but in the interest of backwards compatibility (and compatibility with attribute values on other elements), I think we should probably do the latter. |
Backwards compatibility is a compelling argument, so let's assume the value is a string. The next thing to clarify is whether any kind of type coercion is performed by the processor. For this latter, again two possibilities:
|
Proposal:
Sets opt = string value 3.
Sets opt = integer value 3 (or decimal or whatever XPath does with the expression 3)
Sets opt = a map with two keys. Yes, we're inventing a new escaping mechanism. P.S. If you want a literal ^, you have to escape it |
See also #80 for the questions of coercion. |
Section 4.8.1 Syntactic shortcut for options seems clear enough for atomic types, at least
xs:string
, but it's unclear how to define more exoticly-typed options, like maps.See also #146.
The text was updated successfully, but these errors were encountered: