- From: Norman Walsh <ndw@nwalsh.com>
- Date: Tue, 25 Oct 2011 13:35:20 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2vcrdezzb.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2011/10/20-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 200, 20 Oct 2011
[2]Agenda
See also: [3]IRC log
Attendees
Present
Norm, Vojtech, Henry, Paul, Alex
Regrets
Mohamed, Jim
Chair
Norm
Scribe
Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting: telcon, 31 October 2011 in Santa Clara
4. [8]XML processor profiles
5. [9]XProc issues
6. [10]Issue 014, can steps have foward-references?
7. [11]Any other business?
* [12]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
-> [13]http://www.w3.org/XML/XProc/2011/10/20-agenda
Accepted.
Accept minutes from the previous meeting?
-> [14]http://www.w3.org/XML/XProc/2011/10/13-minutes
Accepted.
Next meeting: telcon, 31 October 2011 in Santa Clara
Accepted. Skipping the telcon next week, meeting 31 Oct/1 Nov in Santa
Clara
XML processor profiles
Henry: Some of the comments had already been addressed. Liam was
commenting on a preceding draft.
Norm: I was hoping to make some progress on the remaining comments, but
didn't get the feedback I requested.
... I think this has to be our focus for the f2f.
<jimfuller> Norm, if we can grab some time next week, I think we can
punch/summarise through most of Michael's comments in about an hour, I
hvae done my first pass and now just need a bit of your time
<jimfuller> then we can summarise to WG
Norm: What about the prose I wrote?
Henry: It seems long, but I'm happy to include it.
Norm: I propose if no one objects, we include it for the next draft. I
think it'll help address at least a couple of comments that we have open.
No one objects.
<jimfuller> +1
Norm: I'll resolve the remaining editorial issues with Paul and the pass
it along.
XProc issues
-> [15]http://www.w3.org/XML/XProc/xproc-candidate-issues/
Norm: Let's look at 013 as a place to start.
Alex: If it's sent back as application/octet-stream, then there's no
information lost because there's no charset.
Norm: So maybe my first suggestion about charset param is not necessary.
Jim: What if you want to override the charset?
Norm: That seems a little odd to me.
Vojtech: We now have c:body and c:data, I think that it would make sense
if they were interchangable. The c:data has a charset attribute.
... Maybe it would be better if we just had c:data or c:body, but if we
have to have both, they should be interchangable.
Norm: We got here by adding c:data late in the process and not really
taking the time to work out the consequences.
... On the basis that c:data has a charset attribute, I think c:body
should as well.
Alex: I'm rereading the section on converting entity bodies, which I know
we've talked about in the past.
... It feels like it could be tightened. It leaves open a lot of
interpretation; especially if you get back something from http-request.
Norm: It also handles application/sparql and application/json.
Alex: We said charset for text/ types, maybe we should have said it for
non-text/ types as well.
Norm: Ok that might be worth reviewing.
Alex: We could at least say non-normatively that the presence of a charset
was a good way to make assumptions about the characters.
Norm: Let's move this up a level; is there anyone who disagrees with
Vojtech's assertion that c:body and c:data should be interchangeable.
Vojtech: There are at least two steps, p:xquery and p:unescape markup that
make explicit statements about c:data, we'd have to allow c:body there as
well.
Norm: My inclination would be to do just that, to say everywhere that we
use c:data that c:body is allowed and vice-versa.
<scribe> ACTION: Norm to write a proposal to do that. [recorded in
[16]http://www.w3.org/2011/10/20-xproc-minutes.html#action01]
Vojtech: It has implications in how p:data and p:http-request are handled
as well.
Norm describes the shortcomings of p:unescape-markup as outlined in the
message
Norm: I think we should default the charset.
Alex: Why can't we auto-detect?
Norm: That turns out to be really, really hard.
Alex: The flip side of that is, that we're guessing too. Forcing them to
guess is good.
Norm: Wait one sec. I did these in the wrong order. Consider my point 3
first. If p:unescape-markup gets a c:body or c:data elment that specifies
the encoding, then it should use that encoding without causing errors.
General agreement.
Norm: describes the problem of a missing encoding in that case.
Vojtech: I think that's a problem in the step that *produced* the data.
Fix it in the http-request.
... Make sure you have what you expected after you get the data.
Alex: If you look at the specification of this step.
... It doesn't say anything about the element that it expects to receive.
Now we're saying if it receives a c:body it can do something with that.
... I wonder if it's better to just have an option that says you should
look at this thing and if it has certain elements or attributes, use them.
... For example, a content-type attribute or a charset attribute. Then you
can have it as whatever you want.
Vojtech: I proposed the same thing in my response.
... We can just have an optional option to enable or disable this
behavior.
Norm: Ok. I don't recall that part of the discussion. Adding an option to
specify that the encoding and/or content type are in attributes on the
incoming element makes sense to me.
... In summary: We don't want unescape-markup to default the charset, you
have to get that right yourself, and we don't want c:data or c:body
treated specially, we want an optional option to specify that content-type
or encoding or charset are encoded in attributes on the root element.
Alex: I wonder if it makes sense to categorize the different situations
and then see what we've got.
... One of the cases that we don't cover well is that I have a random bit
of markup with a content-type attribute. I have to write a pipeline to
pick that out and get it into options.
... Another is the the case Norm has, where you get different responses
from the web.
... It might be nice to outline solutions for the different cases and then
see where we are.
<scribe> ACTION: Alex to outline the various possibilities for input to
p:unescape-markup. [recorded in
[17]http://www.w3.org/2011/10/20-xproc-minutes.html#action02]
Vojtech: What about 014?
Issue 014, can steps have foward-references?
Vojtech: I think it's the case, but it's not clear from the spec.
Norm: I think it is the case however, if you read our import story.
General consensus that it's a case of lazy evaluation.
Norm: There's a related question about lazy evaluation.
... Can you avoid imports if you don't need them?
Vojtech: No, because you have to report static errors.
Norm: So you have to do it half lazily.
Henry: Yeah, that is sort of unfortunate, but I think that's the way it
is.
... It is or is not a static error to write a pipeline that invokes a step
that isn't defined.
Vojtech: Forwards-compatible mode is relevant here..
Norm: In short: we do allow forward references and we do check for static
errors.
Any other business?
None heard.
Adjourned.
Summary of Action Items
[NEW] ACTION: Alex to outline the various possibilities for input to
p:unescape-markup. [recorded in
[18]http://www.w3.org/2011/10/20-xproc-minutes.html#action02]
[NEW] ACTION: Norm to write a proposal to do that. [recorded in
[19]http://www.w3.org/2011/10/20-xproc-minutes.html#action01]
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [20]scribe.perl version 1.135 ([21]CVS
log)
$Date: 2011/10/25 17:34:33 $
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2011/10/20-agenda
3. http://www.w3.org/2011/10/20-xproc-irc
4. http://www.w3.org/XML/XProc/2011/10/20-minutes#agenda
5. http://www.w3.org/XML/XProc/2011/10/20-minutes#item01
6. http://www.w3.org/XML/XProc/2011/10/20-minutes#item02
7. http://www.w3.org/XML/XProc/2011/10/20-minutes#item03
8. http://www.w3.org/XML/XProc/2011/10/20-minutes#item04
9. http://www.w3.org/XML/XProc/2011/10/20-minutes#item05
10. http://www.w3.org/XML/XProc/2011/10/20-minutes#item06
11. http://www.w3.org/XML/XProc/2011/10/20-minutes#item07
12. http://www.w3.org/XML/XProc/2011/10/20-minutes#ActionSummary
13. http://www.w3.org/XML/XProc/2011/10/20-agenda
14. http://www.w3.org/XML/XProc/2011/10/13-minutes
15. http://www.w3.org/XML/XProc/xproc-candidate-issues/
16. http://www.w3.org/2011/10/20-xproc-minutes.html#action01
17. http://www.w3.org/2011/10/20-xproc-minutes.html#action02
18. http://www.w3.org/2011/10/20-xproc-minutes.html#action02
19. http://www.w3.org/2011/10/20-xproc-minutes.html#action01
20. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
21. http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 25 October 2011 17:35:59 UTC