Re: Updated errors draft

I realise that this will cause some eyes to roll, but bear with me...

Namespaces.

I don't want them to be mandatory for error codes, but if I'm throwing errors from within XSLT, I'd like a designated namespace that I may use.

Thoughts?

_________________
Tomos Hillman
eXpertML Ltd
+44 7793 242058
On 28 Mar 2022, 09:20 +0100, Norm Tovey-Walsh <norm@saxonica.com>, wrote:
> Hi folks,
>
> I did a little more tinkering with the errors draft,
>
> https://github.com/invisibleXML/ixml/pull/54
>
> You can preview a formatted version at
>
> https://ndw.github.io/ixml/ixml-specification.html
>
> I wrote a stylesheet to generate the errors appendix, but it has to be
> pasted in by hand. DTD-validated XHTML is just a mess to process.
>
> I realized in the course of writing some of the errors that they’re
> interesting in the following way: they can’t happen in ixml. For
> example, you can’t create an @hex with an invalid hex character because
> the grammar won’t match it. Of course, an implementation still has to
> check for it and raise an error if it occurs because it might arise in
> hand-edited vxml. The error messages just seem a little odd in the spec.
>
> We could take a different approach and produce a normative schema for
> vxml documents. It would then be possible to say simple that it was an
> error if the vxml was not valid. But (a) I’m not sure that would be more
> useful for users, (b) it would require us to construct and agree on a
> normative schema, and (c) I’m not sure implementors are going to be
> inclined to do schema validation every time a vxml document is loaded.
>
> Be seeing you,
> norm
>
> --
> Norm Tovey-Walsh
> Saxonica