XML Processing Model WG

Meeting 171, 15 Apr 2010


See also: IRC log


Paul, Alex, Henry, Norm, Murray, Vojtech


Accept this agenda?

-> http://www.w3.org/XML/XProc/2010/04/15-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2010/02/08-minutes


Next meeting: telcon, 22 Apr 2010?

No regrets heard.

Status update on PR request

Norm: Voting closes today. We've got 12 votes in favor, 1 with a change (the bug we want to fix) and 2 explicit abstentions.

Henry: I hope I did what was needed.

Norm: Yes. Looks fine to me, thanks Henry

-> http://www.w3.org/2002/09/wbs/33280/xproc/results

The default XML processing model

-> http://www.w3.org/XML/XProc/docs/defproc.html

Henry: I basically did what we said. We agreed to two changes.
... Make a new title, and this really is processor profiles, so I chose "XML processor profiles". The XML spec calls what we're talking about "an XML processor".
... I'm not wedded to the name.
... The other thing I did was add another profile.
... I tried to add another profile, to handle xml-stylesheet, but discovered that it was quite difficult.
... What the stylesheet PI does is lay off responsibility to other specs.
... I've reduced my expectations to just trying to get the correct infoset (or data model of choice). Once youv'e applied a stylesheet, or a GRDDL, it's not really "this" document anymore.
... My realizaation is that what I wanted to do with this spec was focus on getting the correct infoset. The fact that I couldn't do the stylesheet story in this spec didn't bother me as much as I thought it would.
... I also had the minor insight that if I was writing the media type registration for, say text/css, I might say something about the processing model profile but that would be in my spec, not in this spec.

Murray: Are there two or three profiles?

Henry: Two, and a discussion of what might be in some other profile.

Murray: I'm sort of sympathetic to the ideas that Henry expressed. I wonder if Paul agrees?

Paul: We can write a pipeline that tells you what to do with an XML document and a stylesheet PI, right?

Norm: Well, for some PIs. For an XSL stylesheet, yes, but for CSS, it's less clear.

Murray: You can load the pipeline into XSL or set a flag to indicate that it was amenable for XSL processing.

Norm: Yes, you could set a variable or option.

Murray: I thought one of the things you could do with the processing model is determine what kind of processing it's eligable for.
... So it might say that XSL was possible, or GRDDL, or other things.

Murray: Would it be useful to write that pipeline?

Henry: Two years ago, when I was trying to get my head around this with my TAG hat on, I produced the elaborated infoset document.
... There's a notion in that which I think I called "elaboration signals". Murray's just reconstructed that idea.
... You've started to list the things that might be in the document that are signals for future processing. For example, encryption.
... Yes, I think that's a useful idea. I've never been able to get anywhere beyond the observation that there are these things.
... It's always seemed to be the case that it's human beings that make the decision about what to do.

Murray: From a QA perspective: the delta between what could be done and what was actually done could be interesting and useful.
... What Henry said earlier about the fact that what XSLT creates for styling is another document, with GRDDL, I guess the same thing is true.
... But in the GRDDL case, it's asserted to be a faithful rendition of the information in this document.
... Another thing about the infoset with respect to GRDDL is that GRDDL decided that you might not have expanded entities, or exposed fixed attributes, etc.

Henry: My inclination is not to bless that. Just because they did it doesn't mean we should make it easy.
... They're going below what we (I) think is the minimum.

Murray: We could give it a name and then explain why you shouldn't use it.

Norm: My concern is that you can't process documents that contain unexpanded entity references. Or documents that aren't namespace well-formed for that matter.

Some further discussion about what the minimum profile means: it expands all entities, fills in attribute default values, etc.

Henry: On a completely different topic, what should our short name be?
... I'm tempted by xprof, but I think the linguistic similarity to 'xproc' is too confusing.

Paul: I suggested 'xml-proc-prof'. An abbreviation of processing profile.

Norm: How about 'xmlprofiles'

<alexmilowski> xmlpp

Murray: It's not an XML profile, it's an XML processing profile.
... And why profile not model?

Henry: My reasoning was that when a spec gives you a set of choices, which is what the XML spec does, then a particular set of values for those choices is what I undersatnd is meant by the word "profile"
... Model is just one of those generic words that's lost all meaning. What would it mean not to be a model? It's just a noun to put after processor.

Norm: Assuming we clean up the editorial issues, would anyone object to publishing this as the first public working draft?

Alex: I really wonder about the xml stylesheet PI issue. I would really like to say something about what browsers do, but maybe that's more than we can achieve.

Murray: Browsers don't do any of this, do they?

Alex: Web browsers do more-or-less apply the XML stylesheet PI.

Some wandering discussion of user agents, media types, stylesheets, validation, etc.

Alex: If we had a processor profile for "apply style" then what the user agent does could be described as "select a stylesheet, through some implementation defined means" then do the "apply stylesheet" profile.

Henry: What I'd like to do is take this document and see if we can get other specs to reference it: HTML5, xxx+XML media types, etc.

Alex: I don't disagree, I just don't know if section 4 needs some tweaking.

Norm: I'd like it out sooner and smaller so we can see what way the community goes with it.
... The community might love it or hate it and I can't predict which.

Murray: I'd like to publish this soon. I'd like to see more detail in it about what we do with the infoset at each step in the process.
... Maybe with a catalog of infoset changes. And I wonder if as part of this process we wouldn't discover new info items to add to the infoset.
... Perhaps we discover that we set particular flags for every pipeline, shouldn't they just be in the infoset.

Norm: Does anyone object to making more-or-less this document our FPWD?

Murray: How about adding a paragraph or two about XML functions and how this document doesn't do that.

No objections heard.

Norm: Now we need a short name.

Some proposals: xml-proc-prof, xppf,




<alexmilowski> xml-proc-profiles


Murray/Henry wrangle a little bit over the title again "profile" vs "model"

Henry: My focus here is what are the invariants that you can count on in the information you get, not how you get it.
... I don't see this as a collection of pipelines

<alexmilowski> "Pipelines for XML Processors" :)



<Vojtech> xmlp?

<PGrosso> I'm liking xml-proc-profiles

<ht> xml-proc-profiles

Proposal: We use the short name xml-proc-profiles

<Vojtech> the short name most likely will contain 'xml' and 'processing', the question is about 'model' and 'profile' - so I wouldn't include it


Henry: I say we get this out by Monday and if no one objects before Wednesday then we go forward.

Norm: Anyone object to that?

None heard.

Any other business?

None heard.


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/04/15 16:34:39 $