Re: Terminology proposals

I started writing a comprehensive reply to Dave’s queries, but many have been answered in the meantime :)

Attached, an updated proposal for edits to the terminology doc.

A few notes:

> ixml processor.  Suggest delete the bracketed para - not a terminology item? Part of the spec?


The bracketed paragraph is there because I think it’s useful to make explicit the limits of the previous sentence: a conformant processor must output vxml for *a* valid parse tree. This could be confusing, since it’s not immediately obvious that a processor doesn’t have to output any *specific* parse tree from an ambiguous parse.

> *ixml input string* used, but not defined.

Placeholder definition added -  I daresay we’ll want to make changes after discussion.

> Is this resulting in a non-accepting state of the parse?


I don’t think we entirely agreed yet whether a partial parse is a categorical failure or not in ixml. It’s not essential to the definition to say whether this is an accept state or not, I don’t think; but we could add that information if we make a decision on the status of partial parses in ixml. (Apologies if I’m misremembering, and we *did* make a decision already.)

> OK, I don't understand this use of prefix. Seems inappropriately
> overloaded here?


I was mainly trying to clarify the original doc’s definition of “prefix recognition” by giving the technical definitions of “prefix” and “proper prefix”. These are very useful for defining a partial parse.

> I like "visible XML", but less enamoured of "vxml", since it makes it sound like it is some special version of XML. I think it should just be "XML" (and it's the only place where XML is involved, as output).


Pragmatically, I’d say that people *will* abbreviate “visible XML” to “vxml”. If we’re going to use the former (I’m glad you like it!), we may as well embrace the latter.

As Norm said, I think it’s essential to have a term for the XML which is output by ixml, as distinct from the XML you might want to generate downstream, which might have features such as schema inclusions, namespace declarations, and so on - which are (currently) not supported by ixml.

I don’t think that the implication that this is a special kind of XML is a bad thing. It helps with explaining why things like schema inclusion aren’t permitted, because it draws a clear distinction between the output of the ixml process (which is a sort of intermediary format, intended to be a structured representation of the content of the input string) and the ultimate output you might want when you’re finished (which will often involve further processing of the ixml output, e.g. by adding other features to the XML (such as schemas and namespaces), or by transforming into another format entirely, etc.).

Maybe “visible markup” would be a better term, though? With e.g. “vMarkup” as an abbreviation?

> I would prefer just "ixml grammar", since an ixml grammar only exists to be an input to an ixml processor.


Makes sense - let me know if the edits I’ve made work for you.

> "constructed from" doesn't work for me. I would prefer "that uses an ixml grammar to recognise an input string". But there is the possibility of confusion here, because we also use "ixml parser" to mean the thing that parses the ixml, rather than the input string (even though, by elaboration, an ixml parser¹ is an ixml parser².)


I made some edits, but I don’t think I’ve caught all the nuances yet; see what you think.

Thanks, everyone! See you soon.

BTW

___________________________________________________ 
Dr. Bethan Tovey-Walsh 
Myfyrwraig PhD | PhD Student CorCenCC 
Prifysgol Abertawe | Swansea University 
Croeso i chi ysgrifennu ataf yn y Gymraeg.

> On 25 Jan 2022, at 11:10, Bethan Tovey-Walsh <accounts@bethan.wales> wrote:
> 
> Hi, all,
> 
> I accidentally replied to a GitHub
> <terminology.md>
> issue email, so the original version of this message was lost. Apologies!
> 
> Attached is an edit of Dave's terminology document. I've proposed some general revisions, and added some terms that I think/hope others may find useful.
> 
> In particular, I've been finding it hard to work out how to distinguish between the direct XML output of the ixml processor, before any extra processing to turn it into a desired output format. It can't really be an "ixml document", because that risks confusion with the ixml input. And just calling it the "ixml output" was becoming extremely frustrating when I wanted to find a way to distinguish it from the result of post-processing it, e.g. to produce JSON, or a different flavour of XML, or whatever.
> 
> Then it struck me that "Visible XML" ("vxml") might be a good term for the output of the ixml processor. It picks up Steven's brilliant "invisible" metaphor, and highlights the main aim of ixml: taking the implied structure of the input string and making it explicit, or "visible".
> 
> I look forward to your comments and criticisms when we meet, and thank you in advance for corrections to any mistakes.
> 
> Very best wishes,
> 
> BTW