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

Places for QName- and map-qname-magic #673

Closed
xml-project opened this Issue Dec 19, 2018 · 5 comments

Comments

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

xml-project commented Dec 19, 2018

Currently we say that we do QName-magic and map-qname-magic for every option and variable declared as xs:QName or map(xs;QName,...)

But I think we want this magic also to happen on attributes of XProc elements like p:output/@serialization or p:inline/@document-properties, don't we?

If so, any idea for a good place to say this?

@eriksiegel

This comment has been minimized.

Copy link
Contributor

eriksiegel commented Dec 19, 2018

Definitely a good idea.

Maybe: Create a section somewhere explaining Qname magic in general and refer to this everywhere appropriate. I wouldn't mind doing this, but after Christmas...

@eriksiegel

This comment has been minimized.

Copy link
Contributor

eriksiegel commented Dec 30, 2018

I would like to propose the following for this:

  • Lets make it the QName magic rule that everywhere where a QName is expected you can also use a string. Rules for conversion as described.
  • The exception for maps that when you have a key that is not a string nor a QName will be skipped should go. Its an exception that no longer makes sense when we treat all QNames as equals. So the conversion of strings-for-Qname-keys in maps is no longer special, it becomes simply an application of the generic Qname magic rule.
  • We rename section 12 to "Variables and options" (now: "Variables")
  • We describe the QName magic is in a short section of its own in section 12.
@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Dec 30, 2018

I am not sure, I agree with your first point:

  1. I thing that QName everywhere is far too much because it would include arrays of QNames, maps defined with QName values or function-items with QName parameters.
    I would prefer to stick to our current consensus to apply QName-magic only for "xs:QName" and "map(xs:QName, ...). So I would prefer to have the two rules (one for each case) instead of a generic rule.
  2. I am not sure where the "drop-key" came from, I would not resist removing it, but if think it doesn't do any harm to keep it.

Since the QName-magic and the QName-map-magic is not restricted to variables and options, but also applies to attributes on XProc-elements, I am not sure this fits under the heading "Variables". Don't you think we need a special section to cover it?

@eriksiegel

This comment has been minimized.

Copy link
Contributor

eriksiegel commented Dec 31, 2018

The QName magic keeps haunting us... (its probably black magic).

I must have understood things wrong because I supposed the everywhere part was already almost there (thanks for correcting me in this). I have no problem with keeping it the way it is defined now. I'll try to do some editing to make it more clear.

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Jan 2, 2019

If the exception about dropping non-name keys is removed, an error will have to be added. You can't turn 42 into a QName so either it's not turned into a QName or it's an error.

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