QT4 CG Meeting 051 Minutes 2023-10-24

• [X] Reece Dunn (RD)
• [ ] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [:10-]
• [X] Michael Kay (MK)
• [X] John Lumley (JL)
• [X] Dimitre Novatchev (DN)
• [X] Wendell Piez (WP)
• [ ] Ed Porter (EP)
• [X] C. M. Sperberg-McQueen (MSM)
• [X] Norm Tovey-Walsh (NW). Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

ATTENTION: Europe and the United Kingdom switch from daylight saving time to standard time on Sunday, October 29, 2023. The meeting on Tuesday, 31 October 2023, will occur at a time one hour later in The United States.

The next meeting is scheduled for Tuesday, 31 October 2023.

No regrets heard.

• [ ] QT4CG-046-01: MK to continue the work on #129 for the other specs (we accepted #703)
• [X] QT4CG-046-04: CG to flesh out changes related to annotations in other parts of the specs
• [X] QT4CG-046-05: NW to updated parse-uri to use decode-from-uri (issue #566)
• [X] QT4CG-048-02: MK to clean up the proposal for adding @as to xsl:sequence and elsewhere
  • MK proposes to close as unclear
• [ ] QT4CG-050-02: MP to attempt to summarize this discussion and identify specific issues
• [X] QT4CG-050-01: MK to revise #749 to retain only the editorial parts.
• [X] QT4CG-050-03: MK to make the proposed editorial improvements to PR #659

See issue #129: does this need to remain open? Can we create actions for the unresolved edits instead?

ACTION QT4CG-051-01: NW to attempt to craft a new issue for the remaining items in #129

See issue #238: time boxed discussion to see if the group wants to do this.

ACTION QT4CG-051-02: NW to attempt to draft a proposal for fn:invisible-xml

See PR #635.

MK introduces the issue.

• MK: We say very little about what happens if you import multiple schemas.
  • … MK reviews what the various specs say, or don’t say.
  • … This PR defines a compatibility relationship between two schemas
  • … It then specifies that schemas must be compatible where they intersect.
• MK walks through the Data Model changes
  • … The most basic comaptibilty condition is that they don’t have different components with the same name.
  • Cases where things can be different (but still compatible):
    • Subsitution group membership
    • Different extensions for the same base type
    • Lax wildcards
  • … When you validate with one schema and then pass the document to another module, there are some gaurantees, but there are also things that can vary.
  • … The rest of the changes are about how these rules are applied.
• RD: Do we want to bring in some other definitions from XML Schema for completeness. There’s a discussion on the XML.com Slack by Adam Retter about the definition of the base type which is defined in XML Schema but not used here.
• MK: Is that directly relevant to this topic, or is it something wider?
• RD: It’s not specific to the schema consistency changes but it’s part of the process of bringing in schemas.
• MK: I think we should have a separate issue for that.

Some further discussion of the type derivation rules and the discussion that took place on the XML.com Slack.

• MSM: My recollection is that there were two schools of thought within the Schema WG and consequently perhaps in the specification about what it meant for one component to point to another. One school of thought was knowing the base type name. The other school of thought was that what you had was transclusion; you had to dereference that pointer so if you had two schemas where the base types were slightly different, they were different even though they had the same name. Connected with this there was a mechanism that allowed one to construct a link of references to the schema components. This meant adding any item to a schema changed all the items in the schema.
  • … What I’m hearing you say is that we expect most people to take the identity of names view.
• MK: I don’t think it makes a difference whether you take the reference as being a name or a pointer to a component. If the names are the same, then the components have to be the same by recursive application of the rule.
  • … The point about a chain of references back up to the root of the tree is more concerning. If that’s the case, then this theory fails. I guess I’d need to search exhaustively to see if there exists such a property.
• MSM: That sounds to me as if there is some non-zero chance that there’s a problem.
• MSM: The second question is, if I do have two incompatible schemas, and I want to use one to validate and expression and then feed it into a stylesheet where a different schema is used. I imagine I’m going to want to say at this point that the processor is going to have to revalidate. Is that feasible?
• MK: I’ve raised a separate issue about multiple schemas where I’m starting to think about being able to import two schemas, give them names, and then say which one you want to validate against. That’s not part of this proposal.
  • … If you want to convert between incompatible schemas, you can’t do that within a single module or stylesheet. Resolving that is another step.

Proosal: Merge this PR.

Accepted.

ACTION QT4CG-051-03: MK to check that in our view schema components don’t indirectly reference the schema root

See #734.

• DN walks us through the function
• DN: One of the features of the fn:chain function is that it adapts the results of the previous function to the arity of the next function.
  • … DN describes the examples
• JL: If we curry this against the first argument, then we have the composition of a set of functions.
  • … We have the arrow operators that allow us to string things together that can handle a number of these static cases.
  • … The difficult bit is going to be modeling what it means when the arity varies across the sequence of functions.
• DN: I didn’t hear a question, but thank you for mentioning the chaining operators. This is useful to know the difference between the arrow operators and fn:chain.
  • … In the arrow operators, we have only expressions, but here we have functions with names. The fact that the arity can change makes the fn:chain function more powerful.
  • … Others have asked about this more complicated case with changing arities. Nothing requires users to use the more complicated case, so I don’t think that’s a point of concern.
• JL: We have two forms of arrow operators now. We have examples where you can go back and forth between those examples. You can use functions and expressions. The thing that what’s much more complicated here is that the list of functions can very variable.
• MSM: Can we clarify briefly the interaction of this wit variable arity functions? I guess if I have a variable arity function that can accept 3, 4, or 5 arguments then I really have three functions.
• DN: Yes, and there are examples that demonstrate these things.
• MK: Function items don’t have variable arity; function definitions can have variable arity from which you can derive funtion items with specific arities.
• MSM: In answering JL’s comment, DN said these are always named functions. But if I’m handing fn:chain a sequence of functions, I can hand it anonymous functions, can’t I?
• DN: Yes, but that would be defeating part of the purpose of this function which is to provide a meaningful set of functions to be applied.

A proposal to accept the PR is made, more discussion follows.

• CG: Can we limit this to arity one functions? It could be hard to understand how this works if the semantics of the function varies depending on the arguments.
• DN: The real power here is to make it possible to do more complicated things, but we aren’t requiring users to use functions with arities greater than one. This is an extension of the idea of chaining.
• CG: In this case, it would be useful to show some examples that require functions that have arities greater than one.
• DN: Yes, we could have many more examples.
• JL: I would say that in the notes for this function, I think it might be useful to say that in simple, static cases, it might be better to use the chaining operators.

ACTION QT4CG-051-04: DN to make the point that in simple, static cases, the arrow operators may be better.

• MSM: Editorially, in item 3 in the list, the fact that the sequence has “N” items is not parenthetical.

ACTION QT4CG-051-05: DN to correct the typo in item 3 “could be sequence” => “could be sequences”.

ACTION QT4CG-051-06: MK to help DN with the markup in fn:chain examples.

Proposal: Accept this PR.

Accepted.