W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > August 2007

XProc Minutes 23 Aug 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 23 Aug 2007 12:12:53 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2tzqqz0u2.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/08/23-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 81, 23 Aug 2007


   See also: IRC log[3]


           Norm, Paul, Mohamed, Rui, Alessandro, Andrew, Murray, Henry,
           Richard, Alex





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 30 August 2007
         4. Comments on the new draft
         5. Advisory type attribute on p:option
         6. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/08/23-agenda

   Amended with item 3, a advisory type attribute for p:option


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/08/16-minutes


  Next meeting: telcon 30 August 2007

   Murray and Alessandro give regrets for 30 Aug

  Comments on the new draft

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

   In particular, 5.7.3 and other recently changed areas per recent email.

   Henry: I'm happy with it and I think Jeni's suggestions are all good and
   not serious.
   ... I would say that when you've worked through the motivation, just above
   the tableau, there's the sentence "the p:namespaces option can be used to
   provide bindings"
   ... I think it should be made clear here that it can be used as an option
   of p:option or p:parameter.
   ... I got to this point and couldn't remember where it went.

   Norm: I agree; I'll fix that.
   ... Any other comments?
   ... Anyone else willing to step up and commit to careful review before COB
   on Monday?

   Mohamed, I'd like more annotations on the types for this review.

   scribe: I think there are some things about option types that are not
   clearly stated.
   ... In particular the distinction between XPath select and XSLT patterns.

  Advisory type attribute on p:option

   Henry: I read Mohamed's recent email suggesting that we ought to have a
   way of providing an advisory type attribute on p:option.
   ... I have mixed feelings because what point is there in having something
   advisory in the language
   ... I can imagine harvesting from someone's declarations and producing a
   ... I wonder what the downside is?
   ... Of offering a type attribute on p:option and p:parameter?

   Norm: And c:parameter?

   Henry: Uhm, I haven't thought that one through; yeah, I suppose so.

   Norm: Are implementations required to test the types?

   Henry: Absolutely not.

   Norm: So they're just strings of any sort.

   Henry: They're a privileged kind of documentation

   Mohamed: It's just like the core steps in the language.

   Norm: ok

   Alex: Are you expecting these to be QName values?

   Henry: I'll probably use QNames, but I don't think we should require them.

   Alex: So then, don't we have a namespaces problem?

   Henry: These types aren't going anywhere.
   ... What this enables me to do is derive a schema from a set of
   declarations which I can use to check pipeline documents that use the
   short name form of options.

   Richard: These appear in the pipeline document

   Alex: The most likely thing is XML Schema simple types.

   Henry: Alas, there's no normative name for XPath expressions.

   Norm: If we don't say what these things are, then we can't check for valid
   bindings. A string with a colon isn't necessarily a QName.

   Alex: Since the namespaces stuff is all there, you're assuming that a
   program would use in-scope namespaces to find the value.

   Henry: The type is being specified by the pipeline author, not the caller.
   So the author knows what the namespaces are.

   Norm: It's just documentation

   Henry: It's not part of the enviroment

   Alex: Then I'm totally against this.

   Henry: It's only available for options during option declaration.

   Alex: Ok, then it should become part of the declaration.

   Norm: Pipeline processors are not supposed to check.

   Alex: That doesn't make any sense.
   ... We'd provide a facility that has an obvious interpretation and then
   not allow you to check that.
   ... That seems weird.

   Murray: I sort of agree with Alex, but perhaps not as vehemently.
   ... Why isn't this an attribute in your names/ace?

   Henry: Because I think it'll be common enough that we might want to
   standardize it.

   Norm: The other point is that it could then appear in the spec (in the
   declarations of the builtin steps)

   Henry: If we're going to define a prefix that we'll use in the canonical
   declare-steps for all the builtins, should we make that facility available
   to users?

   Murray: What I'm hearing is that this isn't a facility of the
   specification, it's just an extra thing that some tools might use but not

   Henry: It is interesting to note that in 7.1.1, it says "the
   attribute-name is a QName value"
   ... What it does not say is "it is a dynamic error if the attribute name
   is not a QName".

   Norm: Yeah, it probably should

   Henry: We could sure simplify the spec by providing types and enforcing

   Norm: We could do that, what bothers me is that it wouldn't check xpath
   expressions and match patterns.

   Henry: I have regular expressions that could do the job.
   ... at least without false negatives.

   Alex: We could just special-case XPaths
   ... I'm just not sure that this is really the way we should go. It's
   really easy for the language of the step to say the type of the thing is
   string but it's an XPath expression and must be valid.
   ... My point is that the type stuff is valuable, but not for checking
   additional constraints like XPath
   ... I'm not sure we want to special case that.

   Henry: There are three possibilities: 1. do nothing; 2. add type and say
   it must be XSD simple type and must be enforced; 3. add an advisory type
   attribute (perhaps as a documentation convention)

   Alex: I'd be interested in 2, but I wouldn't want it to be required.

   Henry: Not required, but it would have to be checked.
   ... So what's changed is we started saying it was documentation now we're
   saying that you can check it.

   Norm: I come back to the fact that what we started with was select vs.
   match and what we've just proposed *doesn't* address that case.

   Richard: Checking against a schema type when you have to check them
   *anyway* in order to implement them, seems redundant.

   Henry: I don't see a problem there. You can produce a schema document that
   has two types for match patterns and expressions that are unconstrained
   subtypes of xs:string.

   Richard: Schema validation is only optional in the whole implementation, I
   certainly don't want to sneak it in just to deal with this.

   Henry: I think the strongest position anyone has taken so far is "you may"
   check against these.

   Richard: I wouldn't want people to be able to declare a component that
   took a restriction of XPath using regex.

   Alex: Implementors can do that if they want
   ... If the original motivation was distinguishing types of XPath
   expressions, I don't think we've come anywhere near that.

   Norm: I'm tempted to do this with an XML comment!

   Henry: I think it's a huge value add if the tableau says "<p:option
   name="attribute-name" type='xs:QName' required='true'/>"

   Alex: I agree, but I think we need to take this further.

   Henry: I can live with that, I think the interesting question is, do we
   say that it's got to be a QName?
   ... that references a type declared in W3C XML Schema, or, ...
   ... is it impl. defined how definitions for these types are found? Or are
   you not allowed?

   Alex: If we're going to put a type attribute there, why didn't you use it
   on your own steps? And so we'd have to pick a library.

   <MoZ> DTLL

   Alex: The obvious candidate is simple types. We'd have to agree that that
   makes sense. I don't see a proliferation of other data type libraries.

   Norm: There's DTLL from DSDL.

   Straw poll: Should we persue some sort of type attribute for options or

   Henry: String, boolean, and integer exhaust the types we'd need to do the

   Alex: There are a handful of token values too.

   Henry: If we said the declarations in section 7 must be enforced, it
   doesn't require a processor to implement XML Schema, just a handful of
   types that they have to implement anyway.

   Results: Yes: 3; No: 1; Abstain: 4; Concur: 2

   Murray: Couldn't we declare the names of the types we're using and provide
   a URI to the definition. Then it's up to the processor to decide whatever
   needs to be done.
   ... That way a processor could decide that it doesn't care, or it can go
   do all the type checking.

   Henry: I think that's helpful; the ones that we need in order to do a
   reasonable job on our on types don't have to be declared, they're already
   declared as used.

   Scribe isn't sure he captured that.

   <scribe> ACTION: Henry to make a concrete proposal in email [recorded in

   Richard: Whatever we decide, it should say somewhere that it's a dynamic
   error for steps to be given options of incorrect types.

   Norm: Yes, we could do that globally.

   Mohamed: Is it possible to have the comments next to each option for the

   Henry: Let's settle the question first.

   Richard: For the case of QNames, we have our own namespace binding
   mechanism. Does XML schema say that they have to be the in-scope

   Henry: Yes, it says that.

   Richard: That's not what we do.

   Some further discussion of what this means

   <p:option name="attribute-name" value="x:foo" xmlns:x="">

   <p:namespaces xmlns:x="..."/>


   Henry: The question that arises is, does this type attribute apply to
   values computed by a select.

   Some more discussion

   Henry: I didn't realize that this applied to value attributes, only
   ... I think it's just wrong to apply it to value. The value of 'value' is
   not a QName in this case.

   Richard: The Schema spec says that the mapping must be in scope in the
   "context in which the value is used". And it's not clear how abstract
   that's meant to be.

   Henry: It meant the element.

   Alex: In this case, we have a special kind of context for in-scope
   namespaces and I think we should be consistent.
   ... I don't think we should have one way to interpret it for value and one
   for select.

   Henry: I disagree.

   Norm: Henry, do you think value='x:foo' and select="'x:foo'"' should be

   Henry: Yes, that's the implication.

   Norm: I suggest we take the rest of this back to email

   Henry: If this is the case, my inclination is to say we shouldn't be
   calling these things QNames.

   Norm: They may not be xs:QNames, but they're QNames.

  Any other business?

   None heard


Summary of Action Items

   [NEW] ACTION: Henry to make a concrete proposal in email [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/08/23-agenda
   [3] http://www.w3.org/2007/08/23-xproc-irc
   [7] http://www.w3.org/2007/08/23-xproc-minutes.html#action01
   [8] http://www.w3.org/2007/08/23-xproc-minutes.html#action01
   [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [10] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[9] version 1.128 (CVS
    $Date: 2007/08/23 16:10:12 $

Received on Thursday, 23 August 2007 16:11:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:44 UTC