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

Content-type of source in p:hash is wrong #78

Closed
xml-project opened this issue Apr 30, 2019 · 6 comments

Comments

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

commented Apr 30, 2019

The source port is flagged as "any" but it has to be "XML HTML" given that the NODE where the hash is inserted is selected by a MATCH-PATTERN.

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented May 1, 2019

Reminder: If we make this change, the result port should also be "XML HTML" and not "application/xml".

@Conal-Tuohy

This comment has been minimized.

Copy link

commented May 2, 2019

It would be nice to be able to insert a hash into a JSON document as well (though some additional wording would be needed, at least, so that map values could be updated, as attribute values can). I don't know how workable that would be; maybe it's enough to convert a JSON document to XML in order to sign it, then convert it to JSON?

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented May 2, 2019

Maybe this can be achieved more naturally if the p:hash step were provided as a function p:hash() with the same signature(s), too? This we’d have to leave for a future spec update though.

There is also an EXPath crypto:hash() function but I doubt that the EXPath crypto module will be available by default in early XProc 3.0 implementations.

@Conal-Tuohy

This comment has been minimized.

Copy link

commented May 2, 2019

There are a few steps whose functionality might be more accessible if provided as functions. For example using p:add-attribute and an XPath function p:uuid could replace the p:uuid step, and p:www-form-urldecode is similar (see #22 (comment)). Functions like p:episode could have been implemented as steps, too (i.e. with a match attribute). I wonder what principled criteria could be adduced for either approach (i.e. on what basis should we have a step in one case and a function in the other)?

I think in general my preference would be for a function rather than a step, because it is more flexible (the value can be assigned to a variable, it can be passed as a parameter, etc, rather than having to be inserted at a particular point in a document).

@ndw

This comment has been minimized.

Copy link
Collaborator

commented May 2, 2019

If I had to give an answer off the top of my head, I'd say "functions don't do node construction". On that basis, p:hash and p:uuid could be functions, p:add-attribute could not.

I have reservations about taking all of the steps that could be functions and turning them into functions, though. That's an awfully large language change pretty late in the process.

@xml-project xml-project self-assigned this May 2, 2019

@Conal-Tuohy

This comment has been minimized.

Copy link

commented May 3, 2019

BTW my mention of p:add-attribute was intended to imply that it was a generic step which could be used in combination with functions like p:uuid(), p:episode(), p:hash(), p:www-form-urldecode(), etc, to replace the specific steps p:uuid, p:hash, p:www-form-urldecode, and so on. But equally those functions could be very useful in other circumstances which don't involve node construction in a document: with p:string-replace, or p:set-properties, or as parameters to p:xslt or p:xquery, or just assigning to a variable.

I don't think there are many such steps that would be candidates for turning into functions. Maybe just these ones?

  • uuid
  • hash
  • www-form-urldecode
  • www-form-urlencode
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.