Skip to content
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

Legacy from 1.0: clarify how syntactic shortcut for options are used with non-string option values #77

Closed
xml-project opened this issue Dec 31, 2016 · 1 comment

Comments

@xml-project
Copy link
Member

clarify how syntactic shortcut for options are used with non-string option values 

This is an aggregation of the discussion on "clarify how syntactic shortcut for options are used with non-string option values" (Issue 161 of the xproc/1.0-specification)

Opened by: rdeltour on 2015-05-27, 16:12h

rdeltour said on 2015-05-27, 16:12h:

Section 4.8.1 Syntactic shortcut for options seems clear enough for atomic types, at leastxs:string, but it's unclear how to define more exoticly-typed options, like maps. 

See also#146

rdeltour said on 2015-05-27, 16:25h:

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.xs:integers, is the following possible? 

<ex:stepType int-option="1"/>

Or should it be interpreted as "a non-string value can only be set with AVT"? 

ndw said on 2015-06-06, 10:17h:

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. 

rdeltour said on 2015-06-06, 11:51h:

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: 

  • only xs:stringoptions can be set that way 

  • type coercion is performed to set options of type xs:string, xs:boolean, xs:double, xs:integer, ???

ndw said on 2015-06-12, 10:37h:

Proposal: 

<ex:step opt="3"> 

Sets opt = string value 3. 

<ex:step opt="^3"> 

Sets opt = integer value 3 (or decimal or whatever XPath does with the expression 3) 

<ex:step opt='^map{"one": 1, "two": 2}'> 

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 itopt="^'^'" 

On 2015-06-12, 10:37h: ndw added the proposed-resolution label.

ndw said on 2015-06-12, 11:13h:

See also #80 for the questions of coercion. 

On 2015-10-07, 14:28h: ndw added this to the XProc 2.0 Next PWD milestone.
@ndw
Copy link
Contributor

ndw commented Sep 15, 2017

Doesn't seem to be an issue here. The value of the AVT is the value of the option. If the option specifies a type (using as=), the value is cast to that type, which either succeeds or fails.

@ndw ndw closed this as completed Sep 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants