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

Still something wrong with QName magic #674

Closed
xml-project opened this Issue Dec 20, 2018 · 14 comments

Comments

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

xml-project commented Dec 20, 2018

I think, we are still not quite right with our description of QName magic. In the spec there is a section starting with:

When prefix-value and namespace-value attributes are available, several additional co-constraints apply:

This applies to steps like p:add-attribute, where we have an option attribute-name and additionally options like attribute-prefix and attribute-namespace. I think this section currently is a left over from the pre-magic times, when we thought of attribute-name as an xs:anyAtomicType. But now we have QName-magic everywhere, so attribute-name is always an xs:QName (either explicitly given by the pipeline author or implicitly created by the processor).

The specs say:

If the supplied value of the name is an xs:QName, you may not specify the prefix-value or namespace-value.

Taking this literally means, specifying the two attributes is always an error, because the name is always a QName. I think what we want is, that the two additional attributes apply only, if the supplied QName is in no namespace.

Is this right or did I miss something?

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Dec 21, 2018

@ndw @gimsieke @eriksiegel
Could one of you please have a look at this issue and tell me, whether I am right or wrong on this.
Any help is much appreciated because this issue currently blocks my work.
Thanks.

@gimsieke

This comment has been minimized.

Copy link
Contributor

gimsieke commented Dec 21, 2018

But is it really true that attribute-name is alaways a QName? Can't we distinguish between the user-supplied, pre-magic value and its sequence type on the one hand and the post-magic QNamized value on the other hand?

Then the following should hold:

Only if the user-supplied value is an xs:string, they may supply attribute-value and attribute-prefix.

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Dec 21, 2018

@gimsike Not sure how you read the specs:

If the value supplied for the option is an instance of xs:string (or a type derived from xs:string), the QName is constructed by following the EQName production rules in [XPath 3.1]. That is, it can be written as a local-name only, as a prefix plus local-name, or as a URI qualified name (using the Q{namespace}local-name syntax). It is a dynamic error (err:XD0061) if the string value is not syntactically an EQName. It is a dynamic error (err:XD0069) if the string value contains a colon and the designated prefix is not declared in the in-scope namespaces.

So to my reading, an instance of xs:QName arrives on the step. And the step will never be able to tell, if the author supplied a string or a QName. Hence your suggestion do not make sense according to my understanding.

What did I miss or which other section of the specs do you rely on?

@eriksiegel

This comment has been minimized.

Copy link
Contributor

eriksiegel commented Dec 21, 2018

@xml-project I agree with your solution:

I think what we want is, that the two additional attributes apply only, if the supplied QName is in no namespace.

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Dec 21, 2018

I still think that we should simply remove the attribute-prefix and attribute-namespace attributes now that we have simple ways to construct a QName in attribute-name, but I'm not going to attempt to persuade you.

On a casual reading, I think @xml-project is correct, but I think we can fix it by saying that the processing is different if attribute-prefix or attribute-namespace are present. I'll take a look.

@ndw ndw self-assigned this Dec 21, 2018

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Dec 21, 2018

I still think that we should simply remove the attribute-prefix and attribute-namespace attributes now that we have simple ways to construct a QName in attribute-name, but I'm not going to attempt to persuade you.

I agree that attribute-prefix and attribute-value (and the other attribute-pairs for the same purpose) are not that useful in XProc 3.0 anymore. But I think we should keep them for legacy reasons.

but I think we can fix it by saying that the processing is different if attribute-prefix or attribute-namespace are present. I'll take a look.

Thought about this way to, but I think this lead us in more trouble than my proposal:

  1. As we state it now, QName magic is a general rule, making processing different would be an exception for certain steps (on a list which get longer over time) in a special situation (presence of the respective options with different names on different steps).

  2. I think it could tear down the difference between the processors duties (QName magic) and the step implementations.

This is why I think it is easier to say, that the processor does always QName-magic (if the option is marked with type xs:QName) and supplies it to the step. The step should then look whether x-prefix and x-namespace are present. If so and the name-option already is in a namespace, an error is raised. If no namespace is present, the step constructs a new QName from name, x-prefixand x-namespace-

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Dec 23, 2018

On closer inspection, I don't see any problems. The first item in the first list in 12.2 begins with "if the supplied value is an xs:QName". That's the case that the first item in the second list is referring to. It even says "the supplied value".

So, this is an error:

  <p:add-attribute attribute-name="{xs:QName('test')}" attribute-namespace="y"/>

But this is not:

  <p:add-attribute attribute-name="test" attribute-namespace="y"/>

Or am I overlooking something?

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Dec 23, 2018

@attribute-name in p:add-attribute is marked as an xs:QName. Therefor (in you second example), the processor is required to do QName-magic and create an instance of xs:QName and supply it as value for attribute-name. So an error is raised just as in the first example

So to my reading, p:add-attribute alway receives an xs:QName-instance. The beginning of 12.2 "if the supplied value is an xs:QName" is void, because its always a QName now.

My proposal is to change to quoted phrase to "if the supplied QName is in no namespace...."

What did I miss?

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Dec 23, 2018

The step only ever receives a QName: a huge and IMHO necessary convenience for step authors.

The processor resolves the value of the attribute-name attribute and considers the supplied value and the other attributes. It's perfectly capable of resolving the difference between my first and second examples.

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Dec 23, 2018

The processor resolves the value of the attribute-name attribute and considers the supplied value and the other attributes. It's perfectly capable of resolving the difference between my first and second examples.

How is the processor supposed to know, that this attributes on this step are special? In XProc 1.0 this was the steps duty, if we move it to the processor (which I do not oppose), we might need a list to do this.

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Dec 23, 2018

After a short line of thinking, I have to revert my opinion: I am strictly against the idea, that the processor in order to evaluate the value of one option has to take into account the presence and the value of other options. This adds a level of complexity into option evaluation which is imho not acceptable: In order to do QName-magic we now have to do option magic.

I still fail to see, why the generation of the actual QName used as name of the attribute to add can not be created in the step based on the supplied values for attribute-name, attribute-prefix and attribute-namespace.

And taking into account that the "option magic" is only necessary for legacy reasons, I now tend to argue, that we should remove x-prefix and x-namespace from all steps.

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Dec 23, 2018

I think it would be unfortunate if we made each step deal with the *-name, *-prefix, *-namespace attributes. But I concede that it's the only way to avoid what you reasonably describe as "option magic". If we're going to do that, then I propose the error conditions also be pushed down into the step. The step will get a QName as the *-name value, so we'll have to say something like *-prefix and *-namespace are only allowed if the *-name value is in no namespace, but it'll be a step error in any event.

Or we can eliminate all this complexity by removing the *-prefix and *-namespace attributes, as you observe 😄

@gimsieke

This comment has been minimized.

Copy link
Contributor

gimsieke commented Dec 23, 2018

Let’s get rid of them.

Migration from 1.0 will become a bit more complicated, but it can still be automated (I think).

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Dec 23, 2018

OK, I give up my support for *-prefix and *-namespace. Let's eliminate them!

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