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

Complicated wording in p:import #771

Open
xml-project opened this Issue Feb 23, 2019 · 4 comments

Comments

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

xml-project commented Feb 23, 2019

In section p:import we say:

A library is considered the same library if the URI of the resource retrieved is the same. If a pipeline or library author uses two different URI values that resolve to the same resource, they must not be considered the same imported library.

I think this section could/should be redone to make it more understandable. I have read it at least four times and I am still not fully sure I know what is meant.

Is this just me?

@gimsieke

This comment has been minimized.

Copy link
Contributor

gimsieke commented Feb 23, 2019

It would make much more sense IMHO if it read:

A library is considered the same library if the URI of the resource retrieved is the same. If a pipeline or library author uses two different URI values that resolve to the same resource, they must be considered the same imported library.

i.e., with “not” omitted.

That is: If, after relative path, catalog, etc. resolution, the resource is the same even if the pipeline author referred to it by ../lib.xpl, file:///path/to/lib.xpl, or http://catalog.resolved.uri/lib.xpl, then the library must be considered the same in all cases.

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Feb 23, 2019

Removing "not" doesn't make any sense. The case you describe, @gimsieke , is already covered by the two paragraphs that precede the quoted text. If ../lib.xpl is a relative reference to file:///path/to/lib.xpl and a catalog resolver resolves http://catalog.resolved.rui/lib.xpl to file:///path/to/lib.xpl, then they all have the same base URI and must be considered the same library. In this case, “redeclarations” of step types must be recognized as actually the same step and not raise an error.

The case that the quoted text is referring to is perhaps a bit pedantic. If I contrive for my webserver to return exactly the same bits from the URIs http://example.com/library-one.xpl and http://example.com/library-two.xml, then those are different libraries. In this case, it will be an error if they contain step declarations with types.

As to @xml-project ’s remark that the text could or should be rewritten to make it more understandable, I have sympathy. But the situation (with circular imports) is devilishly tricky. This prose was the result of a lot of hard thinking about the semantics. Feel free to propose something better, but make sure you understand all of Appendix H before you start :-)

@gimsieke

This comment has been minimized.

Copy link
Contributor

gimsieke commented Feb 23, 2019

Yes, I thought it was just supposed to rephrase what was already said.

I don’t quite understand this sentence in your comment: “In this case, it will be an error if they contain step declarations with types.” Do you mean to say: “In this case, it will be an error if they contain step declarations with identical types.”?

@xml-project

This comment has been minimized.

Copy link
Contributor Author

xml-project commented Feb 23, 2019

@gimsieke :

Do you mean to say: “In this case, it will be an error if they contain step declarations with identical types.”?

Since (per hypothesis) uri1 and uri2 return the same bits of XProc, this will in general be an error (XS0036), unless all p:declare-steps do not have a type-attribute or have visibility='private'. In both cases, nothing is added to the visible steps of the importing step and so no step type is declared twice.

@ndw

The case that the quoted text is referring to is perhaps a bit pedantic. If I contrive for my webserver to return exactly the same bits from the URIs http://example.com/library-one.xpl and http://example.com/library-two.xml, then those are different libraries.

Not sure I understand this: As you said, identity of imported bits is defined via URI of the result. In your example the results have different request AND different result URIs. So I do not see what

If a pipeline or library author uses two different URI values that resolve to the same resource, they must not be considered the same imported library.

adds. But since this sentence is talking about request URIs it confuses me.

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.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.