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

Address two extant FIXME: comments in the spec #699

Merged
merged 14 commits into from Jan 11, 2019

Conversation

Projects
None yet
2 participants
@ndw
Contributor

ndw commented Jan 8, 2019

The first is practically editorial, the second is p:import-functions!

How we managed to close the issue about that before we wrote any prose, I couldn't say. This is a bit minimal, but at least it beats "FIXME".

ndw added some commits Jan 8, 2019

@ndw ndw requested review from gimsieke , eriksiegel and xml-project Jan 8, 2019

@xml-project
Contributor

xml-project left a comment

I was working on this as well and was prepared to send a mail for our call on Thursday.
Here are some additional point, I think we should discuss:
a) For the sake of clarity, I think we need to say, that recursive imports (in the XSLT or XQuery imported) need to be followed.
b) What do we say about competing imports where two imports with the same namespace import a function with the same name? I think we should say it is an error. (Alternative: Take first or last)
c) I think we should have a static error saying: I know (in principle) how to deal with these import - as opposed to XS0103), but this import is defect (a syntax error or a circular import).
d) The content type does not specify the version, so a XSLT 3.0 is to be imported, but I only know, how to handle XSLT 2.0. Is this XS0103?
e) I would like to have a boolean option on p:import-function that say "Raise a static error, if this import fails." This prevents pipeline authors from handling a lot of dynamic errors resulting from unknown function-names in XPath expressions.
f) I would like to see the namespace to be xs:anyURI*, so I can select more than one namespace to be imported and do not have to repeat myself for every namespace.
g) I think it does make sense to add the ability to import a certain content-type to p:system-properties, so one can make an import conditional with `use-when".

ndw added some commits Jan 8, 2019

Merge pull request #698 from ndw/iss-542
Static errors are, uh, static
Merge pull request #697 from ndw/iss-544
Attempt to resolve default input connections
@ndw

This comment has been minimized.

Contributor

ndw commented Jan 8, 2019

We can definitely talk about this on Thursday, but a few thoughts now:

a) For the sake of clarity, I think we need to say, that recursive imports (in the XSLT or XQuery imported) need to be followed.

I think we have to say (somehow) that the imported library is parsed and loaded according to the specifications that govern it. You can't meaningfully load an XSLT or XQuery without parsing it according to its semantics. I think we want to say that without calling out those languages specifically.

b) What do we say about competing imports where two imports with the same namespace import a function with the same name? I think we should say it is an error. (Alternative: Take first or last)

Error.

c) I think we should have a static error saying: I know (in principle) how to deal with these import - as opposed to XS0103), but this import is defect (a syntax error or a circular import).

Yep.

d) The content type does not specify the version, so a XSLT 3.0 is to be imported, but I only know, how to handle XSLT 2.0. Is this XS0103?

I think so. This is a static error, I don't think pipeline authors are going to have too much trouble understanding "I couldn't load it".

e) I would like to have a boolean option on p:import-function that say "Raise a static error, if this import fails." This prevents pipeline authors from handling a lot of dynamic errors resulting from unknown function-names in XPath expressions.

Unknown function names in XPath expressions are static errors, surely?

f) I would like to see the namespace to be xs:anyURI*, so I can select more than one namespace to be imported and do not have to repeat myself for every namespace.

Ok.

g) I think it does make sense to add the ability to import a certain content-type to p:system-properties, so one can make an import conditional with `use-when".

That is a fabulous idea.

ndw added some commits Jan 8, 2019

Merge pull request #701 from ndw/iss-694
Remove use-when exception
@ndw

This comment has been minimized.

Contributor

ndw commented Jan 10, 2019

If the content-type attribute is missing, the processor guesses. If the type is provided and is incorrect, that's an error if it's wrong. The processsor is required to use the specified.

ndw added some commits Jan 8, 2019

@ndw

This comment has been minimized.

Contributor

ndw commented Jan 10, 2019

Fix #704

@xml-project xml-project self-requested a review Jan 11, 2019

@xml-project
Contributor

xml-project left a comment

Looks good to me. Could you have a look at the first line of the last paragraph (5735). Shouldn't it read

(they must not have the same name

@ndw

This comment has been minimized.

Contributor

ndw commented Jan 11, 2019

Yes. Exactly right on the missing "not".

@ndw ndw merged commit c48375a into xproc:master Jan 11, 2019

1 check passed

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

@ndw ndw deleted the ndw:fixme branch Jan 11, 2019

@ndw ndw referenced this pull request Jan 11, 2019

Closed

Document p:import-functions #704

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