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

p:cast-content-type needs an update #16

Open
xml-project opened this issue Apr 22, 2018 · 11 comments

Comments

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

commented Apr 22, 2018

I think we should take a closer look at p:cast-content-type, because it seems to be somewhat outdated by the development of XProc 3.0. Some of my thoughts:

  1. In Prague we agreed that a text document is a text node surrounded by a document node. Since all encoding problems are solved when the text document is created, I think we no longer need a base64 encoding when casting a text document to an XML-document.
  2. Since we define the loading of a JSON document via fn:parse-json(), it seems natural to me to use the inverse function fn:serialize(., map{"method":"json"}) when a JSON document is casted to a text document.
  3. XPath 3.1 defines fn:json-to-xml() which converts a JSON text to an XML-document. It is imho therefore obvious to say, that casting a JSON-document to an XML-document is done via fn:json-to-xml(fn:serialize(., map{"method":"json"})).
  4. Casting an XML-document to a text document seems to be definable via fn:serialize(.).
  5. At least for some XML-documents XPath 3.1 defines a conversion to JSON in fn:xml-to-json(). We could use this to define casting from (some) XML-documents to a JSON documents via: fn:parse-json(fn:xml-to-json()).
@eriksiegel

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2018

??? There is no p:cast-content-type anywhere in the specification. Its probably me but I've never heard of it.

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented Apr 22, 2018

Sorry, but I have to "????" also. If you follow the link in the first line, your will find the step's signature in the standard step library.

@eriksiegel

This comment has been minimized.

Copy link
Contributor

commented Apr 23, 2018

Ah, sorry, sorry. I was looking in the main spec document. My fault.

@ndw

This comment has been minimized.

Copy link
Collaborator

commented May 4, 2018

There's the implementation defined behavior to consider though: casting SVG to PNG, or something even crazier.

@ndw

This comment has been minimized.

Copy link
Collaborator

commented Sep 6, 2018

  • The xml-to-json and json-to-xml conversions must support the XPath 3.1 functions
  • The parameters are used for this conversion
  • An implementation can use additional (namespaced) options to control the behavior
  • The conversion must work for JSON not just text and string JSON text
  • This step could normalize RDF as well

Word this as "you must unless".

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented Oct 21, 2018

I have try to spell out our current discussion on the behaviour of p:cast-content-type. The current content type of the document on port @source is marked as column, the target of the casting (given by @conten-type) is marked in the rows.

to XML HTML Text JSON Binary
XML Change content type If XDM: change content type, otherwise implementation defined. wrap c:data element around text (no base64 endocing) Default: fn:json-to-xml() with serialized JSON. Other castings are implementation defined. Wrap aroud c:data, encode base64.
HTML Change content type Change content type ? ? ?
Text if root is 'c:data' and @encoding="()": Unwrap root element. Otherwise implementation defined. ? Change content type serialize JSON ?
JSON If root namespace is 'http://www.w3.org/2005/xpath-functions': Use fn:xml-to-json(), otherwise its implementation defined. ? fn:parse-json() NoOp ?
Binary If doc root is 'c:data': New binary doc by base64 decoding text child. Otherwise implementation defined. ? ? ? Implementation defined.

As semantics for "?" I propose: "Implementation defined. If the implementation does not know how to perform this casting, XC0071 is raised."

Please comment on this table before I start out the write the prose for the specs.

@ndw

This comment has been minimized.

Copy link
Collaborator

commented Oct 21, 2018

I'm trying to imagine what users would find most useful and/or least surprising.

  1. Would users expect Text to HTML to parse the text as HTML? The HTML 5 rules basically guarantee that any input produces an HTML tree.
  2. If we think Text to HTML should parse, maybe Text to XML should as well. The proposed meaning (wrap a c:data around it) is already possible with p:wrap
  3. Should XML to Text serialize the XML? I guess it should do the inverse of what Text to XML does, so that depends on the answer to point 2.

I don't think those ideas are obviously less correct than what you suggested. And there're a little bit more consistent wrt what you've suggested JSON do.

Thoughts?

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented Oct 21, 2018

I think your proposals absolutely make sense. TEXT to XML is currently defined as the wrapping, but if we do (1), (2) and (3) too.
HTML -> TEXT is then serialize too, isn't it?

I do not have any special preference for one solution or the other. Do you? If not, I propose to let @gimsieke and @eriksiegel decide. May be a topic for next telcon?

@ndw

This comment has been minimized.

Copy link
Collaborator

commented Oct 21, 2018

Yes, HTML to Text should serialize too.

@ndw

This comment has been minimized.

Copy link
Collaborator

commented Oct 21, 2018

Hopefully this will also close #399 and #552

@ndw ndw transferred this issue from xproc/3.0-specification Nov 1, 2018

@ndw

This comment has been minimized.

Copy link
Collaborator

commented Jun 11, 2019

Someone proposed that we were going to use p:cast-content-type to convert parameter sets into JSON.

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.