XML Processing Model WG

Meeting 63, 12 Apr 2007

Agenda

Attendees

Meeting: XML Processing Model WG
Date: 12 Apr 2007
Agenda: http://www.w3.org/XML/XProc/2007/04/12-agenda.html
Meeting number: 63, T-minus 29 weeks
Chair: Norm
Scribe: Norm
ScribeNick: Norm

# Administrivia

Topic: Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/04/12-agenda.html

Accepted.

Topic: Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/04/05-minutes.html

Accepted.

Topic: Next meeting: telcon 19 Apr 2007

Regrets from Henry.

Topic: Monitoring the comments list
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/

Topic: Error handling

Norm: I think there two things we need to address, first is the
semantics of try/catch, the other is what components raise errors and
under what circumstances. Does anyone think there's more to it than
that?

No one suggests there is.

Norm: First, we say that try/catch catches dynamic errors. Second, we
say that the components which raise errors, raise dynamic errors. Is
there more that we need to say?

Alex: The big cases I have to cover are you do a load or httpRequest
and it fails but you want to guarantee a result in the pipeline. This
would also catch XSLT dynamic errors.

Richard: What do we say about error messages?

Norm: T.B.D.

Richard: Some specifications, like XML Schema, say something about the
format of messages. It would be nice if we could capture that.

Alex: It would be nice to have a little vocabulary that's available to
the catch.

Norm: I was thinking of something very simple, like:

  <errors>
    <message type="QName">something</message>
    <error type="QName">something</message>
  </errors>

Mohamed: There's a standard for error messages, EARL. I like something
simple, but if we need something more complex, maybe we should look at
that.

Henry: Isn't that mostly about test suite reporting?

Mohamed: Yes, but it's not clear if they're going to attempt to take a
broader scope. DSDL's Schematron component also has a format for errors.

Henry: I think the thing we have to say is that it is in the nature
of the lack of constraint that we put on implementors that without
try/catch, you have no gaurantees whatsoever about how far or how much
information will come out of a component that subsequently fails.

Henry: I think that nobody downstream of a try-catch will see anything
until after they are gauranteed that no errors occur.

Henry: What happens if there's an error in the catch?

Norm: The pipeline crashes and burns.

Henry: Then you can't say anything about the atomicity of try/catch.
Unless we buffer catch as well, then it could produce a partial
output.

Richard: If we didn't give that guarantee, you could still achieve
that result with a try/catch in the catch.

Norm: You'd have to nest them awfully deep...

Henry: I'm not trying to make a guarantee about success, just about
bounded consequences.

Henry: Straw man proposal: try/catch produces coherent output or
none. If the catch fails, it produces no output.

Norm: It seems to me that buffering in the try is going to be deeper
than the catch.

Richard: Sure, that's a common case, but there are going to be cases
where the try is going to try getting something from one place and the
catch is going to try to get it from another.

Henry: We don't yet have, but maybe we ought to provide, an identity
component that's gauranteed to output only whole documents. It only
produces either complete output or fails.

Alex: Couldn't we do this with an attribute on the catch?

Henry: Maybe we want to think about this for a week, but I kind of
like this idea. I can use it where I don't care if the pipeline fails
but I want to check the well-formedness of the input.

Some discussion of the semantics of this component.

Some discussion of sequences.

You need to be able to know when a sequence ends.

Richard: Suppose we don't have any try/catches, we just have a
pipeline with one of these special identity components followed by an
XSLT component. In the case where there's something wrong with the
document, what happens.

Henry: I thought the pipeline engine was required to check
well-formedness on the connection. The engine itself is required to
halt and catch fire at the first invalid token from the step.

Richard: I'm not sure I like that.

Henry: You have to put an rxp step in between...

Henry: If one uses SAX on every input stream, then the requirement is
satisfied because the SAX inputs will HCF if they see an illformed
document.

Richard: The consequence of this is that an illformed document isn't
going to get any particular kind of error. You won't be able to tell
if it's the substrate or the component that gets the error.

Henry: If I was compiling pipelines into SAX filters, what I said goes
out the window. There's nothing in the SAX filter story that stops
component 7 from producing an illformed sequence of events.

Richard: Suppose an illformed document is output but no one reads it?

Alex: We could say that it's only required to check on input.

Henry: As long as all components do a WF check on the way in, I think
we've satisfied this error.

Henry: What follows from sequencing and the discussion today is that
anyone who does anything interesting before getting their first input
or after producing their last output is asking for trouble.

Norm: What about components that don't consume all their input?

Henry: Are components obliged to consume all their input? I would have
said no.

Mohamend: How in this case do you verify that it's well-formed?

Henry: It amounts to saying that outputs of components like that are
like outputs of components not connected to anything, which isn't very
satisfying.

Alex: It's the underlying implementation that's responsible for
checking.

Henry: In the case where I'm streaming through a large document
looking for a key/value pair and when I find it I'm going to update a
database. I don't see why this component can't declare victory and
complete without ever reading the whole input document.

Mohamed: It's clear for me that this is the general case for for-each
and choose.

Alex: In a particular streaming implementation, you could stop. But in
some other implementation, you couldn't.

Some discussion of SAX/Xerces internals about aborting a parse part
way through.

Topic: Any other business?

None.

Mohamed: What about p:catalog?

Norm: I'll put caching/cataloging back on the agenda for next week.

Adjourned.