Re: Terminology proposals

Tks Bethan for the comments.

ixml processor.  Suggest delete the bracketed para - not a terminology
item? Part of the spec?
Second sentence - sounds more like a requirement? If so, move to spec if needed?


suggest replace ixml processors with ixml processor where sounds reasonable.
People implement the singular (generally :-) )?

*prefix recognition*
Recognition of an *ixml input string* from the beginning to any
subsequent point. If this subsequent point is not equal to the end of
the string, the prefix recognised is a *proper prefix*.
I don't understand that. beginning (of the string?) subsequent point
(within the string?).  Uses *proper prefix* without any definition?

Complete parse
I don't understand this. Minor nits on English. Does this processing
apply solely to the grammar and not the ixml input string? I note the
bracketed sentence mentions consumption of the *ixml input string*. Is
this not the primary function of the *ixml processor* on a successful
parse of the *ixml input string* through to an accepting state?
*ixml input string* used, but not defined.


Partial parse
 Used 'proper prefix' without a definition.
Is this resulting in a non-accepting state of the parse?

(I think I get where you're going with complete / partial parse but
find the wording unclear)
An option:

  A partial parse is defined as processing [by an *ixml processor*] an
*ixml input string* through to some point prior to the end of the
*ixml input string* resulting in a non-accepting state.

A complete parse is defined as processing an *ixml input string*
through to the end of the *ixml input string* resulting in an
accepting state.

HTH

On Tue, 25 Jan 2022 at 11:10, Bethan Tovey-Walsh <accounts@bethan.wales> wrote:
>
> Hi, all,
>
> I accidentally replied to a GitHub
> 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



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.

Received on Tuesday, 25 January 2022 12:00:58 UTC