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

Attempt to fix 94 #146

Merged
merged 2 commits into from Jun 22, 2019

Conversation

Projects
None yet
3 participants
@xml-project
Copy link
Contributor

commented Jun 22, 2019

Attempt to fix #94
Port "attributes" removed and using map as option instead.

@xml-project xml-project requested review from ndw, gimsieke and eriksiegel Jun 22, 2019

@gimsieke
Copy link
Contributor

left a comment

Please don’t close it right away even though I commented it

<p:output port="result" content-types="xml html"/>
<p:option name="match" as="xs:string" select="'/*'" e:type="XSLTSelectionPattern"/>
<p:option name="attributes" required="true" as="map(xs:QName, xs:string)" />

This comment has been minimized.

Copy link
@gimsieke

gimsieke Jun 22, 2019

Contributor

Shouldn’t we allow, in principle, typed attributes, and therefore accept map(xs:QName, xs:anyAtomicType) here?

This comment has been minimized.

Copy link
@xml-project

xml-project Jun 22, 2019

Author Contributor

Fine with me. We then have to say that the value of the created attribute is the string value of the map entry's value, right?

This comment has been minimized.

Copy link
@gimsieke

gimsieke Jun 22, 2019

Contributor

I’m not sure whether typed attributes can only be created when PSVI support is enabled and when the type annotations are conveyed in the PSVI. But then a step is probably not allowed to create such an annotation, because of

In order to avoid these inconsistencies, most steps must not produce PSVI annotated results even when PSVI passing is supported.

(see http://spec.xproc.org/master/head/xproc/#psvi-support). Maybe @ndw can chime in here and enlighten us whether steps may create typed attributes at all.
If not, we might as well only accept string values. I suppose that if people supply, for ex., integers as map values, they’d be typecast to string then without raising an error?

This comment has been minimized.

Copy link
@xml-project

xml-project Jun 22, 2019

Author Contributor

👍

This comment has been minimized.

Copy link
@ndw

ndw Jun 22, 2019

Collaborator

Constructed attributes in XSLT and XQuery are always of type xs:untypedAtomic. I think that's what we should say. The string value as an untyped atomic. (That's good enough for a lot of cases because, for example, if you attempt to add 3 to an untyped atomic, the processor will attempt to make the untyped atomic into a number and will succeed if it's numeric. If we make it of type xs:string, then that doesn't work.)

@ndw

ndw approved these changes Jun 22, 2019

@xml-project xml-project requested review from gimsieke and ndw Jun 22, 2019

@xml-project xml-project merged commit c80ae29 into xproc:master Jun 22, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@xml-project xml-project deleted the xml-project:fix-94 branch Jun 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.