See also: IRC log
Murray asks about XInclude
The input to XInclude is intended to be "the document on which XInclude is to be performed"
Norm observes that Richard may have wanted more time at the f2f and encourages him to post any questions or concerns he finds
Alex reports a few minor changes
Use case 5.6
Norm suggests remove step 3 from the output example
Use case 5.27
This is a subtree/viewport use case
Norm reports that it's clear to him
Use case 5.28
Alex will clarify the use of markers and transformations
Murray suggests calling the marker a "stub" would help
Murray: This use case is a bit prescriptive. But it's a use case not a requirement so it's ok.
Alex: I don't care if we don't meet this use case exactly this way, but I'd like to be able to accomplish it
Use case 5.29
Alex: For something like XQuery,
you might want to simply fail if you don't have the
... But here, you could fall back to XSLT 1.0 if you didn't have 2.0
See also 5.30.
Use case 5.31
Henry: We should consider the
order of use cases, but perhaps not this week.
... I'd like an important aspect of 5.32 to be called out (see the comment in my email)
... The important point is that some of the PSVI properties have to survive across steps
... Note that there's no way to reorder these steps: this is the only order that works because the schema doesn't accept xml:base attributes, but the expansion requires xs:anyURI typed values.
Use case 5.26
Norm: I think we simply need some feedback from the DSDL folks about how validation and transformation relate and how much of that depends on pipelining.
Henry: Step 7 is the interesting step in a use case that claims to be about validation
<scribe> ACTION: Norm to contact the DSDL folks about this use case [recorded in http://www.w3.org/2006/03/16-xproc-minutes.html#action01]
Alex: I don't understand why
there's transformation in the validation use case
... Where's the 'I validated all the pieces but now I know the whole thing is valid' step?
Murray: I think if we have a problem with the use cases, we can just put a comment in indicating an issue
Alex reports that he was planning to make another pass
On the question of order
Murray: I guess the ordering rule
is something I can't describe in detail, but basically the use
cases that concern us most need to be up front. The use cases
that expose issues that are addressed later should be organized
for "progressive exposure"
... Put the 60% use cases first, then the remaining ones after and by the time you get to the last one, you're really way out on the edge
Alex: Ok, that's pretty clear, I can take a stab with those directions.
For next week hopefully, we'll have an improved DSDL use case, we'll have an improved table of use-case/requirement pairings, and a suggested order for the use cases and requirements.
Norm: Personally, I think you should work on the table last because I think it could just be delted.
Alex: Deleting it is one possibility.
Murray: I think it should be
possible to follow your nose from use cases to requirements and
that's as far as I think we have to go
... We'll have to explore any requirements that don't have use cases
Norm: I think it's really
important to get a first working draft of this document out
... So we should plan to vote on that next week or give a really concise summary of what needs to change so that we can vote on the 30th.
Alex: I'll try to go through with an editorial fine-toothed comb
Murray: It'd be valuable to have 24-48 hours of frozen text before I do that
Alex: I'll try to send it out for this later this week.
Murray: For each of the requirements and use cases, I assume there's an ID. Can you expose what they are?
Alex: Yes, I can do that.
Norm: Any other comments?
... Ok, then go ahead and publish it as soon as you can Alex
Norm: In the general realm of
conditional, it wasn't clear to me how to bind xpath
expressions to a particular document
... I thought Alessandro's suggestion of binding the document to the conditional was a clever idea
Murray: What about a test against three documents?
Henry: Are you asking about a conditional that isn't based on the primary
Norm tries to explain his question about conditionals
Henry: I wish Richard was here.
In Richard's ontology, all you have is pipes and components and
you plug them toghether. I think his conception of the
conditional component was one that had one input and no outputs
and that was the conditonal flow.
... So the input to the conditional was the one against which the evaluation was performed
Norm: I think it'd help to see an example like that
Murray: Implicit in what I just
heard from Henry was that there could be any number of
... I could create a conditional that was derived from my own inference engine, for example, and make their determination based on that.
... We could offer a number of conditional components that behave in a variety of ways but we'll never cover all the possible scenarios.
Norm: So it's a component that you can plug in and the component is used to branch on the conditional
Murray: And the component might not return true or false it might set a bunch of different variables
Norm: We'd have to work out how a component could set variables in the environment, which is something we've danced around
Alex: It seems like there's a distinction here between things you can statically analyze and things that are input driven.
Alex: Even if we use a component to do that, which inputs does it use.
Norm: We already have a story of
how components take inputs
... That satisfies my desire to talk about conditionals, we've got more options on the table.
Murray asks about a face-to-face
Murray offers to host a f2f north of Toronto either the week before or after Extreme
Henry: After would work much better for me
Norm: Murray will you post this in mail?
Murray: Yes, I'll try to do that today.
Norm: We are adjourned.