- From: Graydon <graydonish@gmail.com>
- Date: Wed, 5 Feb 2025 21:59:47 -0500
- To: Bethan Tovey-Walsh <bytheway@linguacelta.com>
- Cc: Norm Tovey-Walsh <norm@saxonica.com>, ixml <public-ixml@w3.org>
On Thu, Feb 06, 2025 at 01:00:50AM +0000, Bethan Tovey-Walsh scripsit: > Hi, Graydon, Hello! > Yes, that's the requirements document - I'm sorry, I should have > linked it when I was talking about the requirements in other threads, > to make it a bit more obviously accessible. We have consensus on items > 1-8 so far. The others are still to be decided. Thank you for confirming! (I have been following along, or trying to as neuron availability permits.) > > Can a pragma interact with another pragma? > Requirement 9 says that pragmas must be able to apply to nonterminals, > rules, and whole grammars; Requirement 10 says that adding any other > constructs to that list should only be done if good use cases can be > put forward. These requirements don't preclude the possibility of a > pragma having another pragma as its scope, but there would need to be > strong use cases for adding this capability. > > But your example sounds as though you're talking about something a bit > more indirect, such as the effect of one pragma being somehow > qualified by the effect of a second pragma. That is what I was trying to reference. > I think that would be perfectly feasible; it would be up to individual > implementers to decide whether that kind of behaviour is useful and > reasonable. The impression I have is that "scope" applies to the grammar, so that a pragma (explicitly NOT part of the grammar, becuase it has to be able to be removed without anything happening to the grammar) can't be a scope. That impression could be entirely mistaken, but that's why I went with "interact" rather than as-its-scope. I'm generally inclined to think that pragmas can properly interact, but it seems like something that should be stated in the requirements. >> "Parse tree" is not the same as "document"; does Rule 1 mean that a >> pragma cannot provide dynamic information that would go in the prolog >> of the XML document containing the serialized parse tree produced by >> the grammar? (for example, a time stamp of some kind.) > > That's an interesting question. As you note, the requirement as > accepted by the CG deals only with the XML in abstraction, as a parse > tree, and not in concrete form, as a serialization. I interpret this > to mean that there is some leeway to play with the serialization, > provided that the processor maintains conformance with the > specification. I would agree with that, but again, this seems like something that might benefit from an explicit presence in the requirements. >> As written, I think multiple pragmas with the same name and different >> optional data are permitted. This seems potentially problematic. > > That's the motivation behind Requirements 11, 13, and 15, which state > that pragmas must consist of (at least) a name; that the legal form of > a pragma name must be prescribed by the specification; and that there > must be a mechanism allowing implementers to be certain that pragma > names don't conflict. I think these requirements are necessary for > exactly the reason you've mentioned. That's a rather wider value of "don't conflict" with respect to names than I was thinking of when I read the requirements. Appreciate the clarification. Thank you! Graydon -- Graydon Saunders | graydonish@fastmail.com Þæs oferéode, ðisses swá mæg. -- Deor ("That passed, so may this.")
Received on Thursday, 6 February 2025 02:59:55 UTC