- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 07 May 2009 11:58:17 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2y6t8ewh2.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/05/07-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 143, 07 May 2009
[2]Agenda
See also: [3]IRC log
Attendees
Present
Vojtech, Norm, Henry, Murray, Mohamed
Regrets
Paul
Chair
Norm
Scribe
Norm, MoZ
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting: telcon 14 May 2009
4. [8]The default XML processing model
5. [9]Any other business?
* [10]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
-> [11]http://www.w3.org/XML/XProc/2009/05/07-agenda
Accepted
Accept minutes from the previous meeting?
-> [12]http://www.w3.org/XML/XProc/2009/04/30-minutes
Accepted.
Next meeting: telcon 14 May 2009
Norm must give regrets.
Henry to chair
The default XML processing model
Henry reminds us of the two deliverables from our charter.
<ht> [13]http://www.w3.org/DesignIssues/XML
Henry: Those are Tim's thoughts on this issue.
... Tim's ideas are driven largely by the combination of XML elements from
different namespaces in vocabularies like HTML
... Tim frames the question in terms of "what is the meaning of this
document"? He likes to think about it in a way that I'll characterize
informally as "compositional semantics"
... If you have a tree structured thing, you can talk about its semantics
as being compositional in so far as the meaning of a bit of the tree is a
function of the label on that node and the meaning of its children.
... So a simple recursive descent process will allow you to compute the
meaning of the whole tree.
... It's not surprising that we switch between a processing view and more
abstract statements about the meaning of nodes
... Tim's perspective is that if the fully qualified names of elements can
be thought of as functions, then the recursive descent story is
straightforward.
... That is the "XML functions" story about the document's meaning.
... Another bit of the background is the kind of issue that crops up
repeatedly "now that we have specs like XML encryption and XInclude, when
another spec that's supposed to deal with generic XML
... is created, just what infoset is it that those documents work with if
you hand them a URI. Is it the result you get from parsing with a minimal
parser, or a maximal parser, or one of those followed by ... name your
favorite set of specs ...
... until nothing changes". People keep bumping up against this and
deciding that there should be some generic spec to answer this question.
... That's where the requirement in our charter comes from
So GRDDL could have said "You start with a blurt infoset" where a spec
such as ours could define what blurt is.
Henry: I ran with this ball in the TAG for a while.
<ht> [14]http://www.w3.org/2001/tag/doc/elabInfoset/elabInfoset
Henry: This document is as far as I got.
... It uses the phrase "elaborated infoset" to describe a richer infoset
that you get from performing some number of operations.
... That document doesn't read like a TAG finding, it reads like a spec.
... So one way of looking at this document is as input into this
discussion in XProc.
... I think the reasons this stalled in the TAG are at least to some
extent outside the scope of our deliverable.
... They have to do with the distinction between some kind of elaborated
infoset and the more general question of application meaning of XML
documents.
... Fortunately, we don't have to deal with the latter.
... Hopefully, folks can review these documents before next week.
Norm: They make sense to me
Norm: My concern with my chair's hat on is that there are lots of ways to
approach this. Perhaps the right thing to do is start by trying to create
a requirements and use cases document?
Murray: Can we do that by pointing to all the existing documents?
Henry: I think we could benefit from a pointer to Murray's discussion on
the GRDDL working group mailing list.
... I'm thinking that what this is primarily is a way of defining a
vocabulary that other specs can use.
Murray: Would I be way off base thinking that a net result of this process
will be a pipeline written in XProc?
Henry: The process I described above requires you to repeat the process
until nothing changes.
Norm: You could do it, you'd end up doing it n+1 times, but you could do
it with p:compare.
Henry: It'd have to be recursive, it'd be a little tricky, but I guess you
could do it.
Murray: It seems to me that if we can't answer part 2 by relying on part
1, then we didn't complete part 1 properly.
... If you can't produce an elaborated infoset by running it through a
pipeline, then you did something wrong in the pipeline.
... Otherwise, what hope does anyone else have in accomplishing this.
Henry: It seems entirely possible to me that there are operations that on
the one hand need to be specified as primitives in our view of things and
on the other hand are not necessary for any of the use cases that get us
over the 80/20 point.
... I'm not yet convinced that there aren't things in that category that
you need.
Murray: Maybe that'll provide the imputus for XProc v.next
... If I have a document that purports some truth, but I have to go
through lots of machinations to get there, but there's a formulaic way
then we should be able to use the tools to do it.
Henry: I believe, thoughI I'm not sure, that you could implement XInclude
by writing an XProc pipeline that didn't use the XInclude step. Doing so
might reveal something about the complexity of XInclude.
... If someone said you don't need to do that, you can always write a
pipeline, I'd say "No, wrong, you could but you wouldn't want to."
Norm: If we get to the point where we think we could do it, but we needed
a few extra atomic steps, I think we could call that victory.
Henry: Let me introduce one other aspect, in attempting to do this in a
way that doesn't require a putative spec to be rewritten every time some
new bit of XML processing gets defined,
... the elaborated infoset proposal has this notion of "elaboration cues"
and attempts to define the process independent of a concreate list of
these cues.
... I'm not sure how valuable that attempt to be generic is.
Norm: I think one possibility is to define a concrete pipeline that does
just have a limited set of steps.
Henry: Doesn't that mean that if we add a new obfuscation step, that
de-obfuscation requires us to revisit the elaborated infoset spec?
Norm: Yes.
Murray: Right, we're talking about the default processing model. Henry's
talking about the obfuscated processing model which would be different.
... You can petition later to become part of the default.
Henry: Another way of putting it is, should the elaboration spec be
extensible?
Norm: Right. And one answer is "no".
<MoZ> Scribe : MoZ
Murray: it looks like it has been done in other spec. What we need to do
is to define the processing model for the most common cases
Henry: my experience is that it will be easier to have agreement on
elaboration to allow people to control what is elaboration and what isn't
... The default is to have XInclude but not external stylesheet
... Some want to have XInclude, some wants external stylesheet and other
wants both
Norm: I agree, but will it make any progress on the problem ?
Henry: it will depends on the conformance story
... what I had in mind was : if GRRDL is coming out, and has the ability
to say that the input of the processing is a GRDDL elaborated infoset
Murray: what happen to XML document that is not anymore an XML Document
(Encryption, Zipping, etc...)
Henry: I agree, that's all we talking about
<Norm> scribe: Norm
Some discussion about which technologies preserve the "XMLness" of a
document.
Encryption and Henry's obfuscation example both produce XML documents
Mohamed: It's an interesting discussion. There is, I think, a common base
on which we can at least agree.
... These are more technical than logical, for example, XInclude,
encryption, where the behavior is clearly defined.
... On top of that, there's a layer of user behavior. I think we'll have a
hard time at that layer.
... Defining the use caes and requirements is probably the only place we
can start.
Norm: Yeah, I don't want to make us do work that's already been done. But
I think there would be value in collecting the use cases together
... to see if we have agreement that some, all, or none of them are things
we think we could reasonably be expected to achieve.
Murray: Hopefully more than none.
Norm: Indeed.
... Ok, for next week, let's plan to have reviewed the documents that
Henry pointed to and spend some time on use cases and requirements.
Henry: Agreed.
Any other business?
None heard.
Adjourned.
Summary of Action Items
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [15]scribe.perl version 1.135 ([16]CVS
log)
$Date: 2009/05/07 15:57:33 $
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2009/05/07-agenda
3. http://www.w3.org/2009/05/07-xproc-irc
4. http://www.w3.org/XML/XProc/2009/05/07-minutes#agenda
5. http://www.w3.org/XML/XProc/2009/05/07-minutes#item01
6. http://www.w3.org/XML/XProc/2009/05/07-minutes#item02
7. http://www.w3.org/XML/XProc/2009/05/07-minutes#item03
8. http://www.w3.org/XML/XProc/2009/05/07-minutes#item04
9. http://www.w3.org/XML/XProc/2009/05/07-minutes#item05
10. http://www.w3.org/XML/XProc/2009/05/07-minutes#ActionSummary
11. http://www.w3.org/XML/XProc/2009/05/07-agenda
12. http://www.w3.org/XML/XProc/2009/04/30-minutes
13. http://www.w3.org/DesignIssues/XML
14. http://www.w3.org/2001/tag/doc/elabInfoset/elabInfoset
15. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
16. http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 7 May 2009 15:59:02 UTC