Skip to content

Raw Minutes, 7 Feb

Jump to bottom
Achim Berndzen edited this page Feb 14, 2018 · 10 revisions

Wednesday, 7 Feb

Present: Martin, Gerrit, Erik, David, Achim, Christophe, Romain, Matthieu, Jim, Bert, Ari, Geert

Prioritized Agenda

Wednesday

  • What are we presenting?

  • On Thursday

  • The pre-conference day workshop

  • On Saturday

  • The status report to the community

  • Action items: who’s doing the things we decided?

  • Next meeting?

  • XML London?

  • XML Amsterdam?

  • Balisage?

If we have time agenda:

  • Detailed questions from other agenda page

  • Issues list

  • Step library discussion

  • Review XML London minutes

  • Validation report

  • Review Norm’s proposal for "inejectable" debugging steps

  • Test suite

Revisit importing function libraries

  • Erik: When we talked about importing functions, we said that you could not import global variables. Is there a technical reason for this?

  • Gerrit: It could make the analysis of the pipeline more difficult.

  • Norm: I don’t know if it’s technically possible or not. It would defeat static analysis of XPath expressions.

  • Gerrit: You could do static analysis of the imported document.

  • Norm: Only if it’s available at "compile" time…​

  • Achim: The encapsulation of XSLT is hidden behind the p:xslt step.

  • Erik: I want to be able to refer to global variables in my XProc pipeline just like I can refer to functions.

  • Norm: Let’s create an issue to see if this is possible.

  • Matthieu: What about other things like xsl:key?

  • Gerrit: It could be handy to use key expressions in XProc pipelines.

Created #269 to track this.

Added: This is Issue 292

  • Achim: Note that if you did this, the imported variables would shadow all of the options or preceding variables that have the same names.

  • General agreement: yes.

Detailed questions from the other page

Enhance p:zip?

Enhance the functionality or the manifest that feeds the zip creation: Add the possibility to create files-in-the-zip from ports in the pipeline (given that this port has sequence=false). So then you have three possibilities for this: A file from disk, a literal file in the manifest and a port output.

  • Achim: I think the zip step is still pretty rudimentary. We’ll all have ideas for how to make it better. That’s going to be a central step. Would you be willing to try to spec it out more concretely?

  • Erik: Yes.

  • Martin: We proposed a p:archive step, https://github.com/xproc/steps/issues/3

What about writing to disk?

Use the same mechanism (the same manifest?) for creating a file/directory structure on disk?

  • Erik: A zip file is almost like putting files on disk. Could we use the same mechanism?

  • Norm: Seems reasonable to me. There’s a format option on the proposed p:archive step; having a "filesystem" or other value that means write the structure to a directory seems reasonable to me.

  • Romain: Is there some way that we could design the formats, for example, for the list of files that could be reused across steps.

  • Achim: So a c:file, c:directory, etc. defined for all steps.

  • Norm: I think this is just a request to standardize the manifest separately.

  • Erik: And if we want the manifest to be complete, we probably need serialization parameters for each XML document.

Some discussion of where to publish this. An appendix, perhaps, or a separate specification.

  • Norm: Erik, can you be thinking about that when you work on the archive step?

  • Erik: Yep.

p:tee

Add a p:tee step. Much easier and more low-threshold solution than the current proposal about diagnostics (we could have both). Add a disable option to the step so you can easily switch it off when not debugging

  • Erik: In Aachen we talked about a complex diagnostics framework. I think a p:tee step would also be beneficial.

  • Norm: That’s the same as v1.0:

` <p:identity version="1.0"> <p:log port="result" href="/log/me/here.xml"/> </p:identity> `

  • Erik: Yes. I also added an enable/disable flag to turn off the output.

  • Achim: I don’t like the flag very much.

  • Martin: We have a similar step called store-debug that does the same kind of thing. It would be nice to have serialization options on this step.

  • Gerrit: We use a file: URI with query parameters to set serialization options.

  • Martin: See, http://transpect.github.io/modules-xproc-util.html#tr-store-debug

  • Norm: I suggest you (Erik) make a proposal for a p:tee step as an issue on the steps repo.

  • Erik: Ok.

Added: This is Issue 293

Recursive directories?

Make it possible to read recursive directory structures directly.

  • Norm: I think we already agreed to do this.

  • Erik: Ok.

Added: See Issue 234

p:group?

What is meant with this for p:group: A group is specified by the p:group element. In a p:try, it is a non-step wrapper

  • Norm: I think this whole "wrapper"/"container"/"non-step wrapper" terminology is fatally flawed. Needs rewriting.

  • Achim: We’ve also made big changes to variables.

Norm waffles on a bit about how this came to be. Ugh.

p:finally

What is meant with: The p:finally has no inputs and no outputs. It exists only to handle recovery and resource cleanup tasks. If cleanup tasks require access to readable ports, put them in the p:catch block of an enclosing p:try.

  • Norm: It runs after a failure, so it can’t read or write anything.

Norm waffles on a bit about using catch; will try to improve that last sentence.

Names on p:catch/p:finally

Why do p:catch and p:finally have name attributes (and p:when/p:otherwise don’t)

  • Norm: I don’t think they’re necessary

  • Achim: I think they’re useful for error reporting. I think we should add name to p:when.

  • Norm: Uuuuhhhm…​ok. I worry that people will think they can connect to them.

  • Martin: It’s complicated when you have a beginner learning XProc.

  • Christophe: Maybe use a different.

  • Norm: xml:id

Consensus: remove the name attribute from catch and finally.

Added: This is Issue 294

  • Achim: What about a name on p:group in p:try? Should we get rid of the double use of p:group.

  • Norm: You don’t actually need the wrapper…​

  • Ari: If you want to generate the pipeline the p:group is very handy. I’d object to removing it.

Today we have:

` <p:try> <p:group> <my:stuff1/> <my:stuff2/> </p:group> <p:catch>…​</p:catch> <p:finally/> </p:try> `

This wouldn’t actually be ambiguous:

` <p:try> <my:stuff1/> <my:stuff2/> <p:catch>…​</p:catch> <p:finally/> </p:try> `

The p:group would still be allowed, but it would no longer be required.

Consensus: remove the requirement to have a p:group wrapper as the first child of p:try.

This is Issue 283

Viewport output

An output port of a viewport is stated as primary in the spec. So do you have to say primary="true" when declaring it?

  • Norm: No, you can have at most one p:output so it will be primary if you specify it. The point of that statement is to make it clear that the output will be primary even if you don’t specify it explicitly with a p:output.

What is the default value of @expand-text?

true() See also #270

Serialization parameters

The explanation of the serialization parameters is not very detailed. Where can I find more information? (e.g. method is unexplained and has no value list, what do the normalization-form-s do, etc.)

Required options?

What is the default value of p:option/@required

false() See #272

Pipes and with-input

Why does the use of @pipe exclude the use of p:pipe, p:document and p:inline on a p:with-input? Seems unnecessary…

  • Achim: Because the order is unclear.

  • Erik: I think we should specify that anything in the attributes goes first.

  • Achim: And I thought they should go last.

  • Erik: I don’t think that’s logical. They’re syntactic sugar.

Further discussion of the order. Because href and pipe aren’t ordered, we don’t allow you to mix things that are ordered with things that aren’t.

Content type and p:inline

What does this mean with the p:inline: It is a static error (err:XS0071XPS) if the content type value specifies a character set and the encoding attribute is absent.

This is an error because the characters are already literally in Unicode:

` <p:inline @@content-type="application/xml;charset=ISO-Latin1"> this is a test </p:inline> `

The charset is either wrong or useless.

This could be valid because the base64 characters when decoded will be a sequence of bytes which can have a charset.

` <p:inline @@content-type="application/xml;charset=ISO-Latin1" encoding="base64"> dGhpcyBpcyBhIHRlc3QK </p:inline> `

p:load and dtd-validate

What happens when on a p:load you set dtd-validate to true and the doc has no DTD ref

  • Norm: I think answer is, nothing happens. See #273

p:language system property

Where does p:system-property(p:language) gets its value from?

  • Norm: XML Calabash 1.0 returns Locale.getDefault().toString.replace('_', '-')

  • Achim: Morgana returns "English" because the messages produced by Morgana are always in English.

  • Erik: So there’s disagreement here.

  • Norm: Yes. So what is the point of p:language.

Some discussion about what this is for. One possibility is for messages. Another possibility is for selecting things like hyphenation tables.

  • Gerrit: We often have a language option that we pass around in our pipelines.

  • Romain: What are the use cases? Sometimes the language is not enough.

  • Norm: Does anyone think that p:locale needs more justification?

  • Achim: It’s easy to expose, so let’s expose it.

  • Norm: Do we want a p:language as well, and what does it mean, exactly?

  • Achim: I’m not sure. The V1.0 test suite asks for the language.

Consensus: we should rename p:language to p:locale and return the locale.

Added: This is Issue 296

p:namespace

I don’t understand the example given for p:namespace. I must honestly say I no longer understand p:namespace at all, even I remember understanding it more-or-less in Aachen.

  • Norm: Oh, god.

Norm works his way slowly through the example in the spec. Clumsily.

  • Achim: Can I suggest we remove this because we now have EQnames.

  • Norm: "I love you, man." YES!

Looking for topics to fill 20 minutes before lunch…​

Next meetings

General discussion of summer dates. Irrespective of whether or not there is an XML London conference, there is good reason to believe that there will be an XML conference of some sort in June in Europe.

  • Achim: We’ve made a lot of progress on the core spec, but I’m still unsatisified with progress on the step library. I think we should have a meeting in June to focus on the step library.

  • Norm: Yes. I would especially like to see proposals for JSON steps.

Some discussion of the utility of JSON steps. First focus is on useful steps for XML programmers forced to work with APIs that only support JSON.

Norm: I can investigate getting a conference room for a couple of days in MarkLogic.

Proposal: next workshop to be colocated with a summer conference in London. Precise details TBD, but announcement expected within a week or so.

Follow-up on the mailing list to nail down details.

Step library questions

  • Achim: For the purposes of announcing a "compatible processor", can we nail down the 3.0 steps in some way before the summer?

  • Gerrit: We talked about adding an option to compare to support other kinds of comparisons.

  • Achim: When can we say we’ll be done?

  • Erik: Sounds like the spec is nearly done. The implementations are the holdup.

  • Christophe: We can publish a release candidate for the step library and you can say you’re compatible with that.

Some thoughts for the step library:

  1. Publish the steps30 spec with only the required steps.

  2. Make the following steps required: p:hash, p:in-scope-names, p:uuid, p:www-form-urldecode, p:www-form-urlencode, and p:run. (Added: This is Issue 298)

  3. Remove the p:template step because it isn’t necessary anymore. (Added: This is Issue 297)

  4. Publish "Optional validation steps" as a spec containing p:validate-with-* (Added: This is Issue 300)

  5. Publish p:exec as a separate spec

  6. Publish p:xquery as a separate spec

  7. Publish p:xsl-formatter as a separate spec

Added: The last three points are Issue 299

Plan to publish the core spec and these specs in some sort of candidate recommendation state "this spring".

Announcement

Erik Siegel has agreed to join the editorial team! Huzzah!

What are we presenting?

  • On Saturday

  • Report that we met several times

  • Report that we’re making good progress

  • Road map:

  • Last call drafts "this spring"

  • Core spec and step spec "candidate releases" ready by June

  • Implementations commensurate with CR by June

  • Test suite

  • Erik’s Programmer Reference for 3.0 also planned for June

  • Remind folks where to get the specs

  • Remind folks who’s on the editorial board

  • Remind folks who generally comes to the workshops

  • Invite participation!

  • Point to the current candidate specs

  • Summary page showing issue closed/resolved

  • Call out for use cases for non-XML steps

  • document-properties, document model (non-XML documents, XDM concept of document) XPath 3.1, maps, importing functions (e.g. XSLT and XQuery), Attribute and text value templates, other syntactic simplifications, tunneled options, no more parameter input ports

  • State of the implementations

  • What are we presenting?

  • On Thursday

  • The pre-conference day workshop

  • Call out for use cases for non-XML steps

Clone this wiki locally