Re: [xsl] Where is 'intersect' Operator Defined in XPath 3?

["Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

>I assumed that at least each function (nd other component) of the language
would have a few paras of explanation; but specifically would occupy something
like a <sect*> to itself at some level, with the name of the function in the
<title>, or perhaps as the xml:id

Actually, we use a much more structured vocabulary for function
specifications:

https://github.com/qt4cg/qtspecs/blob/master/specifications/xpath-functions-4
0/src/function-catalog.xml

This is then pre-processed to generate narrative text using the xmlspec
vocubulary, which is then transcluded into the prose document.

The same is true of the grammar:

https://github.com/qt4cg/qtspecs/blob/master/specifications/grammar-40/xpath-
grammar.xml

and the XSLT element proformas:

https://github.com/qt4cg/qtspecs/blob/master/specifications/xslt-40/src/eleme
nt-catalog.xml

but the rest of the content is essentially in narrative documents, using the
xmlspec DTD.

As regards indexing, the main question I think is whether to index only on
glossary term references (which are extensively marked up in the text), or on
free unstructured text. And there are the usualy questions you get when
indexing a book: should you index words like "football" that appear only in
examples? (My view, yes you should, because someone is going to remember that
there's a football example and wants to find it. But ideally for a term like
xsl:value-of, the index will distinguish occurrences in prose text from
occurrences in examples.)

>assigning to subcommittees, etc.

We've tended to maintain separate documents for administrative checklists,
rather than adding this inline to the specification text. But the
specification text sometimes includes some administrative metadata, for
example change markings might carry the date the change was agreed and the
date it was applied. Examples are often annotated with the language/construct
to which they conform, to enable both syntax highlighting and syntax
validation.

Michael Kay
Saxonica



> On 11 Aug 2022, at 21:18, Peter Flynn peter@xxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On 10/08/2022 18:43, Norm Tovey-Walsh ndw@xxxxxxxxxx wrote:
>>> I doubt it is beyond those on this list (or the WG?) to auto-create an
>>> index (despite W3C constraints) into all recs?
>> Indexing is hard, intellectual labor. But it might be possible to do
>> something with the markup in the specs.
>
> I was hoping to elicit this response when I asked about the file format.
>
> In my abundant ignorance of the editorial process I assumed that at least
each function (nd other component) of the language would have a few paras of
explanation; but specifically would occupy something like a <sect*> to itself
at some level, with the name of the function in the <title>, or perhaps as the
xml:id.  It is then trivial to list them all, with a view to indexing,
checking, assigning to subcommittees, etc. But perhaps I have been working
with structured document systems for too long :-)
>
> Peter