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

Add p:force-qname() function? #641

Closed
eriksiegel opened this Issue Nov 17, 2018 · 12 comments

Comments

Projects
None yet
4 participants
@eriksiegel
Contributor

eriksiegel commented Nov 17, 2018

To solve the problem of xs:Qname keys in maps we added a p:force-qname-keys() function that is applied by magic to options with maps with xs:Qname keys.

Now we do the same kind of magic on xs:Qname types options, So it would be consistent to add a p:force-qname() function and describe the mechanism in the same way (that this, function is magically applied to options of xs:QName type).

@gimsieke

This comment has been minimized.

Contributor

gimsieke commented Nov 17, 2018

Maybe we can rename p:force-qname-keys() to p:force-qnames(item()) and define it like this:

If the argument is a QName ⇒ return it unchanged.

If the argument is a map ⇒ current p:force-qname-keys() behavior

If the argument is of type xs:string it is transformed into an xs:Qname using the XPath EQName production rules. That is, it can be written as a local-name only, as a prefix plus local-name or as a URI plus local-name (using the Q{} syntax).

XD0061 should also be thrown if the string can’t be transformed into a QName (or different error code depending on whether a map or a string was supplied).

A new dynamic error for arguments other than map, string, or QName should be thrown.

Also a new paragraph in http://spec.xproc.org/master/head/xproc/#varopt-types:

As a convenience, if the specified sequence type is xs:QName, the p:force-qnames() function is automatically applied to the value. This makes it possible to pass xs:string type values that are converted automatically into the required xs:QName.

@eriksiegel

This comment has been minimized.

Contributor

eriksiegel commented Nov 17, 2018

Sounds like a plan to me. Maybe even:

p:force-qname(item()*) so it works on sequences as well (each item in the sequence is treated the same)

@xml-project

This comment has been minimized.

Contributor

xml-project commented Nov 17, 2018

Could you please give me a brief hint, in which situations I might like to use p:force-qname()?
As far as I understood it, the magic is down by the processor, so I currently fail to see, why a pipeline author might need this function.

@gimsieke

This comment has been minimized.

Contributor

gimsieke commented Nov 17, 2018

Will pipeline authors invoke p:force-qname-keys()? I think this function has been created to make the magic that the processor is supposed to apply a bit more transparent.

@xml-project

This comment has been minimized.

Contributor

xml-project commented Nov 17, 2018

Will pipeline authors invoke p:force-qname-keys()?

If this is to say, no one will ever call it, I propose to remove it from the specs. We could use the prose but free the implementers from additional and unnecessary work.

@gimsieke

This comment has been minimized.

Contributor

gimsieke commented Nov 17, 2018

I don’t know whether there will be pipeline authors who’d like to call these functions explicitly. Therefore I don’t have a strong argument in favor of exposing it as a function, apart from “it makes the magic more transparent”.
I don’t know how much extra work will go into exposing as a p: function a normalization routine that an implementer would have to write anyway.

@xml-project

This comment has been minimized.

Contributor

xml-project commented Nov 17, 2018

  1. Since XPath function rely on the underlying XPath implementation they are always at risk, if the XPath vendor changes her API. So if we are sure, it is only for the purpose of the specs, I would strongly argue to remove it.

  2. This brings me back to my initial question about a use case for p:force-qname().

@eriksiegel

This comment has been minimized.

Contributor

eriksiegel commented Nov 18, 2018

I don't have a use-case at hand either. But since once upon a time we decided to call the p:force-qname-keys() to life, it would be consistent to either create a p:force-qname() or throw them inexorably on the garbage pile of killed darlings and other once seemingly good ideas...

Both options are fine with me.

@ndw

This comment has been minimized.

Contributor

ndw commented Nov 29, 2018

Consensus at editor's meeting 29 Nov: we don't need to expose p:force-qname-keys() to the user. We'll remove it from the p: namespace.

@eriksiegel

This comment has been minimized.

Contributor

eriksiegel commented Dec 4, 2018

So, are we there? As far as I understand, what we've decided now is:

  • When an option has an explicit datatype map(xs:QName, ...) we do QName magic on the QName keys when giving it a value with p:with-option
  • When an option has an explicit datatype xs:QName we do QName magic on the values when giving it a value using p:with-option

Correct? These are the only circumstances where we apply QName magic? Not when setting variables with the same datatypes, not when an option is an array(xs:QName). (I'm not advocating to enlarge the scope of the QName magic, just want to be sure).

@ndw

This comment has been minimized.

Contributor

ndw commented Dec 4, 2018

I think that's the effect we want. I started making a front-to-back pass over the document and what I discovered (wrt this item anyway), is that:

  1. The section on map(xs:QName,...) appeals to the p:force-qname-keys() function so it's not going to be a simple matter of removing the function; the description is going to have to be merged in somewhere else.
  2. The spec actually describes the transformation of options of type xs:QName into QNames explicitly, without appeal to the function.

Somehow those things have to get harmonized. I think it's probably ok to keep them separate, but it would be ok (with me) to merge them if that was the clearer description.

Every time I think I should work on this, I notice that Achim assigned it to himself and I'm off the hook 😄

@xml-project

This comment has been minimized.

Contributor

xml-project commented Dec 4, 2018

@ndw Since your english is better than mine: Go on, assign yourself. 😄
No, seriously: If you want to work on something, remove my assignment and go on. On Thursday or Friday I will take a longer time to work on (some of) my assignments.

On all
I think that it is fairly odd, that the magic for xs:QName applies for options, but not for variables. So

<p:option name="opt" as="xs:QName" select="'name'" />

works, but

<p:variable name="var" as="xs:Qname" select="'name'" />

is an error because it assigns a string to a QName.

Pretty sure, people will hate us for this. I thought we already agreed on this, but obviously not. Do not see, why not. So: Lets have the map and QName-magic with variables as well!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment