Re: revised text and diagram

On Wed, 12 Jan 2022 at 19:04, Tom Hillman <tom@expertml.com> wrote:

> Sorry to be a pain, but can we move away from specifically talking about
> text and XML “files”?  I think it’s equally valid to talk about strings and
> XML nodes.
>


Tom, since you undErstand that usage, please propose additional text
expressing such usage?

Regards

>
> _________________
> Tomos Hillman
> eXpertML Ltd
> +44 7793 242058
> On 12 Jan 2022, 6:55 PM +0000, Dave Pawson <dave.pawson@gmail.com>, wrote:
>
> Thanks Michael.
>
> On Wed, 12 Jan 2022 at 17:47, C. M. Sperberg-McQueen
> <cmsmcq@blackmesatech.com> wrote:
>
> Comments on the text please?
>
>
> In the paragraph on ixml grammars in XML, the text reads
>
> 2. *ixml grammar XML file*. An ixml file specified in xml. Is there
> a schema of some ilk to which such an xml may tested? This
> expresses the language [alphabet?] which may be used to constrain
> input files valid to that language.
>
>
> No official schema for the XML form of grammars exists; it is not hard
> to make one, and the schemas I have created are in the archive of this
> mailing list since I posted them in response the last time this question
> came up. (Two schemas, one allowing extension attributes.)
>
>
> Can I assume this will be in / referenced from the spec?
> Suggest *ixml grammar XML file*. An ixml file specified in xml and
> valid to the appropriate schema.
>
>
>
>
> In the context of parsing and formal languages, 'alphabet' has a
> technical meaning, and it's better to avoid it in the final sentence
> above. The grammar defines a language. Possible alternatives to the
> final sentence:
>
> This can be used to constrain the input.
>
> This can be used to make explicit the structure implicit in the
> input.
>
> This defines a language and can be used to check and identify the
> structure of input files in that language.
>
>
> I prefer the last of these three, but none give any indication of
> compliance,
> validity or some other way in which the *text input file* obeys the
> language
> specified by the *ixml grammar file". How about
>
> "This defines a language and can be used to check the
> input files against the language of the *ixml grammar file*"
>
>
>
>
>
>
>
> In describing the text input file I would steer clear of speaking about
> 'intent'. Many uses of ixml will be parsing documents created for other
> purposes and often without any intent to follow any grammmar rules at
> all.
>
>
> Suggest " A *text input file* Written by an ixml user which may be checked
> against the *ixml grammar file* "
>
> (On the assumption that if written for some other purpose it is
> outside the scope
> of the spec)
>
>
> There are no pragma files in ixml as currently specified, and no
> proposals for pragma files. I would delete that box and that section of
> the text.
>
>
> I disagree, though I will if all mention of pragmas disappears from
> the meetings?
> I am guessing that some wording will be drafted for pragmas in the near
> future?
> Isn't that what you and Tom are working towards?
>
>
>
>
> I don't understand the description of the ixml processor; if it takes
> three inputs, what are they? If it takes four, what are they?
>
>
> Inputs are
> One of xml or text grammar
> input file
> [pragma 'file' to be removed, wording on xml grammar to include pragmas.]
>
> These were the four files.
>
> Proposed update on 1. *ixml grammar*
>
> 1. An ixml grammar, expressed in either text (valid to the spec) or in
> an XML version thereof. Either may express the grammar to be used
> for processing a *text input file* into output. Optionally, pragmas may
> be included to affect the grammar.
>
> Updated * ixml processor* definition.
>
> * ixml processor*
>
> An application taking as input a grammar and *text input file* and
> producing the output. Its task is to validate the text input file
> against the given grammar and if valid produce the *ixml output* following
> the
> grammar . Errors detected may [shall?] be produced and
> shown to the user.
>
> Unless otherwise directed, suggest 'shall' be used for errors.
>
>
> I'll produce rev 0.e tonight.
>
> regards
>
>
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
>
> --
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.

Received on Wednesday, 12 January 2022 19:27:54 UTC