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

Attribute "content-type" on p:inline/p:document after static variables #470

Closed
xml-project opened this Issue Jul 25, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@xml-project
Contributor

xml-project commented Jul 25, 2018

If I remember right, we introduced @content-type on p:inline/p:document so we can determine the document type statically, while @document-properties is determined dynamically.
Now we have static variables/options and @document-properties on p:inline/p:document is evaluated during static analysis:
Do we still need @content-type or could we rely just on the entry in @document-properties?

@ndw

This comment has been minimized.

Show comment
Hide comment
@ndw

ndw Jul 25, 2018

Contributor

Hmm. I'm confused again. We really seem to have tangled ourselves up on this issue. I prefer @content-type because it's easier to type and I think it'll be fairly common. I think we have rules now for static analysis of inputs/outputs/etc. on p:declare-step. It's not immediately obvious to me that this needs to apply globally. Consider:

<p:declare-step version="3.0" xmlns:p="http://www.w3.org/ns/xproc" name="main">
  <p:option name="method" static="true" select="'xml'"/>
  <p:output port="result" serialization="map { 'method': $method }"/>
  <p:option name="href"/>
  <p:option name="ctype"/>

  <p:identity>
    <p:input port="source">
      <p:document href="{$href}" content-type="{$ctype}"/>
    </p:input>
  </p:identity>
</p:declare-step>

Why did we decide to forbid that?

Contributor

ndw commented Jul 25, 2018

Hmm. I'm confused again. We really seem to have tangled ourselves up on this issue. I prefer @content-type because it's easier to type and I think it'll be fairly common. I think we have rules now for static analysis of inputs/outputs/etc. on p:declare-step. It's not immediately obvious to me that this needs to apply globally. Consider:

<p:declare-step version="3.0" xmlns:p="http://www.w3.org/ns/xproc" name="main">
  <p:option name="method" static="true" select="'xml'"/>
  <p:output port="result" serialization="map { 'method': $method }"/>
  <p:option name="href"/>
  <p:option name="ctype"/>

  <p:identity>
    <p:input port="source">
      <p:document href="{$href}" content-type="{$ctype}"/>
    </p:input>
  </p:identity>
</p:declare-step>

Why did we decide to forbid that?

@xml-project

This comment has been minimized.

Show comment
Hide comment
@xml-project

xml-project Jul 25, 2018

Contributor

Yes, I am confused to. In the current specs we say

Several kinds of expressions are evaluated during static analysis: [...]
3. The document-properties of p:inline and p:document elements.

and @content-type is no AVT on p:inline and p:document.

So the content-type can only be set statically. content-type="{$ctype}" (from the example) will be an error, because it is not a valid form of a content type.

Beside: Why is document-properties to be determined static? Intuitively would prefer to keep it dynamic, so I can use it to pass (non-static) option values to steps using the map. But as we decided it to be static, there is obviously something I have overlooked something, but what?

The reason to make content-type static what issue #426, but that was specific for p:inline, so may be we got it wrong for p:document. Keeping in mind, that we define p:document via p:load, reading the specs let me concluded, that the content-type for p:document can only be set statically (see quoted rules), but it can not be determined statically. In p:load we say, that if there is neither a @content-type nor an respective entry in @document-properties, that the content-type is determined by the content-type delivered from the file-system (http: etc.)

Apart from the static/dynamic problem, I would agree to keep content-type as syntactic sugar, because it is easier to write content-type="text/plain" then document-properties="map{'content-type':'text/plain'}" -- Hope I understood @ndw 's argument right.

Contributor

xml-project commented Jul 25, 2018

Yes, I am confused to. In the current specs we say

Several kinds of expressions are evaluated during static analysis: [...]
3. The document-properties of p:inline and p:document elements.

and @content-type is no AVT on p:inline and p:document.

So the content-type can only be set statically. content-type="{$ctype}" (from the example) will be an error, because it is not a valid form of a content type.

Beside: Why is document-properties to be determined static? Intuitively would prefer to keep it dynamic, so I can use it to pass (non-static) option values to steps using the map. But as we decided it to be static, there is obviously something I have overlooked something, but what?

The reason to make content-type static what issue #426, but that was specific for p:inline, so may be we got it wrong for p:document. Keeping in mind, that we define p:document via p:load, reading the specs let me concluded, that the content-type for p:document can only be set statically (see quoted rules), but it can not be determined statically. In p:load we say, that if there is neither a @content-type nor an respective entry in @document-properties, that the content-type is determined by the content-type delivered from the file-system (http: etc.)

Apart from the static/dynamic problem, I would agree to keep content-type as syntactic sugar, because it is easier to write content-type="text/plain" then document-properties="map{'content-type':'text/plain'}" -- Hope I understood @ndw 's argument right.

@xml-project

This comment has been minimized.

Show comment
Hide comment
@xml-project

xml-project Jul 27, 2018

Contributor

For consensus see minutes of 26-July-2018

Contributor

xml-project commented Jul 27, 2018

For consensus see minutes of 26-July-2018

@ndw

This comment has been minimized.

Show comment
Hide comment
@ndw

ndw Sep 5, 2018

Contributor

Overtaken by events.

Contributor

ndw commented Sep 5, 2018

Overtaken by events.

@ndw ndw closed this Sep 5, 2018

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