XML Processing Model WG -- 08 Apr 2015

Date: 8 April 2015

<scribe> Meeting: 269

<scribe> Scribe: Norm

<scribe> ScribeNick: Norm

jfuller: are you calling in?

<jfuller> I am here

Accept this agenda?

-> http://www.w3.org/XML/XProc/2015/04/08-agenda

Accepted.

Next meeting

Proposed: 15 April 2015 does anyone have to give regrets?

<ht> Regrets for 15/4

Review of open action items

<scribe> No progress reported.

"Merge" concepts of ports and options, issue 109

-> https://github.com/xproc/specification/issues/109

Jim: Things have moved on a bit; so this may not be relevant anymore.

<jfuller> https://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2014Feb/0001.html

<ht> I thought we had actually already discussed this???

Jim summarizes Romain's message.

Jim: I think in the end, the idea of addressing ports with XPath expressions is off the table.
... The other half of the issue is addressed by the @bind shortcut.
... I think we can close this without action.

Norm: Ok. I think Romain will raise another issue (or reopen this one) if there are particular details that we haven't addressed.

Henry: I would be very sorry to lose the basic architectural nature of ports and steps. As essentially a data flow language.

Norm: I propose that we close this and see what happens?

No objections heard.

Proposal for p:validate step

-> https://github.com/xproc/extensions/blob/master/steps/validate.md

Norm attempts to summarize

<jfuller> comment for the scribe - on issue #109, I think the work we did with opening up options, providing @pipe and allowing non xml docs flow all strengthen the current architecture with demarcation between options and ports

Alex: Can we generalize beyond the model PI.

Can we have definitions of group and phase that are generalized, or should they simply be parameters.

Norm: That didn't occur to me at the time, but making them parameters might be a good idea.

<alexmilowski> http://www.w3.org/2013/ShEx/Primer

Alex: There's a validation language for RDF stuff

Norm: That's the RDF Shapes work, I think.

Alex: I think we should make sure that we are aligned with these technologies.

Norm: I'll move group and phase to the parameters.

<scribe> ACTION: A-269-01 Alex to review the RDF Shapes work and see if this validation step will cover that use case. [recorded in http://www.w3.org/2015/04/08-xproc-minutes.html#action01]

<scribe> ACTION: A-269-02 Norm to review the current state of play wrt to JSON schema and see if we can cover that use case too. [recorded in http://www.w3.org/2015/04/08-xproc-minutes.html#action02]

Jim: Is there any context where there's some symmetry with assertions here.
... If not, is there any work of a p:assert mechanism.

Norm: I think you can do assertions with XPath expressions and the p:error step.

Jim: It seems like we're putting a facade over existing steps to provide a single entry point. When I was thinking about this, I was thinking about what's the same about assertions.
... I'm wondering if we need some symmetry at that level. A single entry point for assertions.

ACTION A-269-03: Jim to raise an issue with some specific examples of the kinds of assertions he has in mind

Alex: I wonder if we need a kind of scale of validity.

Norm: I think that's what the report port is for, if you don't specify assert-valid then you can expect a report of what the result of attempted validation was.

Alex: Is there work on this?

Henry: Yes. If you demand a single answer, you often get "no" but if you want more detail, XML Schema validation does generate multiple values.

Alex: You can consider structural validity vs datatype validity etc.

Henry: That's not a million miles away from what's done, but it's done in a different direction. The use cases we had in mind were things like a bank transfer where the validity of some fields wasn't considered important.
... The two three-valued features are roughly speaking, "I had enough information to attempt validation on none/some/all of this document and I found that of the parts I was able to validate none/some/all of it was valid."
... Then you get individual remarks about individual bits of invalidity.

Alex: I wonder if it makes sense to make recommendations for common parameters.
... You could have a parameter called outcome and it has one of those values.

Norm: I think that's what you get from the report port.

Alex: How do we choose to validate?

Norm: I added parameters for the validation technologies we know about!

Alex: I could imagine a situation where you send the validation spec two schemas (XML Schema and RELAX NG) and my processor has some way to do validation twice.
... Does it make sense to have names you can define.

Norm: What's a name?

Alex: The name is the type of validation you want to attempt.

Norm: But one point of this step is that it doesn't know what kind of validation it's going to do until it looks at the input document and (in the case of XML) finds the xml-model PI.
... I left open the possibility of passing in a model.

Murray: The report port, is that like sending something to a log file.

Norm: Yes, except that it's intended for downstream steps to interpret.

Henry: In fact my now out of date validator produced a document and had a stylesheet.

Murray: Surely there's a name that's more general for a port like this?

Henry: I don't know one. Most compilers just spit stuff out on stderr.

Norm: The term "report" is what Schematron uses.

Alex: Could we make this simpler by having a single port for 'report' and 'validation attempted'?

Norm: Yes, probably. I was trying to make it possible to know what was done without necessarily knowing the format of the report.

Murray: So the implementation is going to do its thing with with some technology that we don't know.
... The implementor knows what all the messages are.
... The step should not only provide the services it should also have a known report format.

Alex: It would be nice to have a vocabulary for the report, even if its non-normative.
... I think that should be in the spec. It's implementation defined but you can use this.
... For report. For validation-attempted, that should be something that's defined.

<scribe> ACTION: A-269-04 Norm to define the validation-attempted output format and propose a non-normative report structure [recorded in http://www.w3.org/2015/04/08-xproc-minutes.html#action03]

<scribe> ACTION: A-269-03: Jim to raise an issue with some specific examples of the kinds of assertions he has in mind [recorded in http://www.w3.org/2015/04/08-xproc-minutes.html#action04]

NOTE TO SCRIBE FIX THE ISSUE NUMBERING

Alex: The other suggestion I want to make is that we add a section on validation with Schematron.

<scribe> ACTION: A-269-05: Norm to make sure there's a "Validation with Schematron" section. [recorded in http://www.w3.org/2015/04/08-xproc-minutes.html#action05]

Alex: I also think that we should have examples that show how to do the same thing with p:validate that we used to do with specific validation steps.
... I think people will gravitate towards the p:validate step

Henry: I strongly disagree that there should be any attempt to produce a report format, even for validate-attempted. There's such tremendous variety in what's debated and produced, that it's an 18 month research project.

Alex: I hear you, but in that case we have to put a big warning in the spec.

<jfuller> at the edge, looking into an abyss ....

Henry: Even assert-valid requires someone to map the outcomes from schema validation to that bit. The schema spec itself does not provide you with that bit.
... The XML Schema spec only tells you two three valued numbers.
... I think this step should explicitly say that the outputs are implementation defined; so the implementor has to document them so you'll know what they are.

Murray: But not interoperably?

Henry: No.

Some research into what the current p:validate-with-xml-schema step says about assert-valid; it appears to say very little.

<alexmilowski> http://www.w3.org/TR/xproc/#c.validate-with-xml-schema

<scribe> ACTION: A-269-06: Henry to review the current p:validate-with-xml-schema step and see what we should possibly say differently [recorded in http://www.w3.org/2015/04/08-xproc-minutes.html#action06]

Alex: For each of the languages we're going to enumerate, if we're going to, we need to define what assert-valid means.
... Users aren't going to be satisfied if we say the whole thing is completely implementation defined.

Any other business?

Jim: One point of p:validate is to enable new validation technologies, right?

Norm: Sortof.

Henry: Yes, but it does mean we have to tell implementors that they have to define how assert-valid is defined.

Alex: Let's push this off for two weeks until Henry returns.

<jfuller> have a great break Henry !

Adjourned.

- DRAFT -

XML Processing Model WG

08 Apr 2015

Attendees

Contents