Using Emacs nXML mode to validate XHTML5 using the v.Nu schemas: support for HTTP-based schema URI?

Using Emacs nXML mode to validate XHTML5 using the v.Nu schemas: support for HTTP-based schema URI?

[Graham Hannington]

I am using Emacs nXML mode to validate XHTML5 documents with the Nu Html 
Checker (v.Nu) schemas.

Sincere thanks to all who made this possible, including the developers of:
- Emacs (and Chris Zheng, for providing an Emacs for Windows binary at 
http://emacsbinw64.sourceforge.net/)
- nXML
- The GitHub repo hober/html5-el, which provides the datatype library 
required by the v.Nu schemas in a Lisp-based format usable by nXML (rather 
than, say, a Java-based library usable by Jing)

I'm grateful and happy. But I could be even happier, hence this email.

Rather than using a snapshot of the v.Nu schemas downloaded to my local 
file system, I'd like to refer to the "living" v.Nu schemas in the GitHub 
repo via HTTP.

I can already do that in other validating XML editors that use Jing 
(again, thanks to Mr Clark), such as jEdit. I'd like to do that in Emacs, 
too.

For example, in emacs\share\emacs\24.5\etc\schema\schemas.xml (those 
backslashes betray the fact I'm using Emacs on Windows :-) ), I want to 
specify:

  <uri pattern="*.xhtml" typeId="XHTML5"/>
  <typeId id="XHTML5" uri="
http://unsoup.github.io/validator/schema/xhtml5-all.rnc"/>

For background on why I'm referring to an "unsoup" URL rather than 
directly to the v.Nu repo, see:

https://github.com/unsoup/validator

(I must update that readme to mention raw.githubusercontent.com as an 
alternative to github.io URLs.)

However, that "http://..." uri attribute value causes the following error 
in Emacs:

> Invalid URI: "URI `http:/// ... ' does not use the `file:' scheme"

so, for now, I'm pointing to a snapshot of the v.Nu schemas on my local 
file system.

That's okay - it's working, which is great - but I'd prefer to point to 
the "live" schemas via HTTP.

I'd appreciate advice on adding support for HTTP URLs to that uri 
attribute value (and also include directives in the .rnc files) or, better 
still, an update to nXML that includes this support (I'm not a Lisp 
programmer, but I could learn).

Regards,
Graham Hannington

Fundi Software Pty Ltd  2016  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

Re: Using Emacs nXML mode to validate XHTML5 using the v.Nu schemas: support for HTTP-based schema URI?

[Stefan Monnier]

> - The GitHub repo hober/html5-el, which provides the datatype library 
> required by the v.Nu schemas in a Lisp-based format usable by nXML (rather 
> than, say, a Java-based library usable by Jing)

Ha!  I put something very similar into GNU ELPA's html5-schema package
a month or so ago.

>> Invalid URI: "URI `http:/// ... ' does not use the `file:' scheme"
> That's okay - it's working, which is great - but I'd prefer to point to 
> the "live" schemas via HTTP.

It might not be too hard to tweak nXML so it accepts HTTP URLs, but I'm
not sure what behavior you'd want to see exactly: the naive approach
might download all those files via HTTP every time you open an HTML
file, slowing down startup significantly.

It could also use a cache, but then it begs the question of how often to
update the cache.  So for my kind of use-case at least, I'd end up
preferring to manage the file by hand (i.e. download the files via
"git" and update them via "git pull" whenever I feel like it).

> I'd appreciate advice on adding support for HTTP URLs to that uri 
> attribute value (and also include directives in the .rnc files) or, better 
> still, an update to nXML that includes this support (I'm not a Lisp 
> programmer, but I could learn).

If you enable url-handler-mode, then Emacs will consider "http://..." as
a valid file name.  So assuming you enabled that mode, you should mostly
need to teach nXML to accept those names.  E.g. the 100% guaranteed
untested patch below might be a good start.


        Stefan


PS: I'd welcome some help to improve the html5-schema so that the HTML
    it accepts includes SVG elements.


diff --git a/lisp/nxml/rng-uri.el b/lisp/nxml/rng-uri.el
index 8fc0a01..76f9bc1 100644
--- a/lisp/nxml/rng-uri.el
+++ b/lisp/nxml/rng-uri.el
@@ -82,10 +82,11 @@ rng-uri-file-name-1
     (cond ((not scheme)
 	   (unless pattern
 	     (rng-uri-error "URI `%s' does not have a scheme" uri)))
-	  ((not (string= (downcase scheme) "file"))
-	   (rng-uri-error "URI `%s' does not use the `file:' scheme" uri)))
-    (when (not (member authority
-		       (cons (system-name) '(nil "" "localhost"))))
+	  ((not (member (downcase scheme) '("file" "http")))
+	   (rng-uri-error "URI `%s' does not use the `file:' or `http:' scheme" uri)))
+    (when (and (equal (downcase scheme) "file")
+               (not (member authority
+                            (cons (system-name) '(nil "" "localhost")))))
       (rng-uri-error "URI `%s' does not start with `file:///' or `file://localhost/'"
 	     uri))
     (when query

Re: Using Emacs nXML mode to validate XHTML5 using the v.Nu schemas: support for HTTP-based schema URI?

[Graham Hannington]

Hi Stefan,

Re:

> the naive approach...

Good point.

> It could also use a cache

Yes, jEdit does this, but I can't see myself getting the time to (a) learn 
Lisp and (b) implement something similar for Emacs nXML, so I'm going to 
drop this idea for now.

Thanks for the patch anyway, that's very kind of you.

Re:

> I'd welcome some help to improve the html5-schema so that the HTML it 
accepts includes SVG elements.

Yes, I can help, but be prepared for some tedious detail. If you're prone 
to responding "tl;dr", look away now ;-).

From the description of the html5-schema package (
https://elpa.gnu.org/packages/html5-schema.html):

> The RelaxNG files are taken straight from 
https://github.com/validator/validator.git's via:
> git subtree -P schema/html5 split

The problem with that approach - taking files "straight" from the v.Nu 
GitHub repo - is this:

> Some schemas in the v.Nu GitHub repository - in particular, schemas that 
combine markup languages - refer to file paths that do not exist in the 
repository. The paths exist only in the context of the distributed files 
(inside vnu.jar).
> These nonexistent paths prevent the schemas being usable directly from 
the v.Nu repo (for example, via GitHub Pages URLs).

For details, see the readme at (my) repo:

https://github.com/unsoup/validator

As described in that readme, I extracted the schemas from vnu.jar and 
compared them with the schemas in the repo.

Today, prompted by your email, I went two steps further:

1. I developed a Microsoft Windows PowerShell script (sorry, that's my 
primary working environment) that completely automates a process that I 
had previously done manually:

a. Downloads the latest release of the vnu.jar .zip from GitHub
b. Extracts vnu.jar from the .zip
c. Copies the schema files from their single ("flat") directory in vnu.jar 
to a directory of your choice, re-creating the same relative directory 
structure as the URI paths used by v.Nu.

The result is a set of schema files that matches what v.Nu uses, with 
relative include paths that work.

2. I uploaded the results of running that script to:

https://github.com/unsoup/validator/tree/gh-pages/schema-release

To improve the html5-schema package, replace its contents with the 
contents of the unsoup/validator/schema-release directory (perhaps minus 
the readme).

That is: use the v.Nu schemas from vnu.jar, not from the GitHub repo.

To "accept" SVG elements in an XHTML5 document, use the following schema 
file:

xhtml5_rdfalite.rnc

which matches the Validator.nu "preset":

XHTML + SVG 1.1 + MathML 3.0 + RDFa Lite 1.1

For details, see the readme at:

https://github.com/unsoup/validator/tree/gh-pages/schema-release

(I might add to that readme a table that matches Validator.nu presets to 
schema file names.)

Let me know how you get on.

I plan to upload that PowerShell script in the next few days.

In time, I might even schedule that script to run every so often, and 
introduce further automated steps, to get the latest-release vnu.jar, 
extract its schemas, and commit any changes to the copy in the 
unsoup/validator/schema-release directory.

Cheers,
Graham

Fundi Software Pty Ltd  2016  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

Re: Using Emacs nXML mode to validate XHTML5 using the v.Nu schemas: support for HTTP-based schema URI?

[Stefan Monnier]

>> I'd welcome some help to improve the html5-schema so that the HTML it 
>> accepts includes SVG elements.
[...]
> The problem with that approach - taking files "straight" from the v.Nu 
> GitHub repo - is this:

Cool, so you seem to have the knowledge I lack.  I don't have time to
provide the knowledge you lack right now, but I'll get back to you later
on this.

> Some schemas in the v.Nu GitHub repository - in particular, schemas that 
> combine markup languages - refer to file paths that do not exist in the 
> repository. The paths exist only in the context of the distributed files 
> (inside vnu.jar).
> These nonexistent paths prevent the schemas being usable directly from 
> the v.Nu repo (for example, via GitHub Pages URLs).

Do you know how/when/where those missing files get generated?


        Stefan

Re: Using Emacs nXML mode to validate XHTML5 using the v.Nu schemas: support for HTTP-based schema URI?

[Graham Hannington]

> Do you know how/when/where those missing files get generated?

How: yes.

By the v.Nu Python build script, build.py:

https://github.com/validator/validator/blob/master/build/build.py

When: no.

At least, not precisely. Imprecisely, the bleeding obvious ;-): whenever a 
v.Nu developer, or anyone else who clones the repo, decides to build v.Nu 
from source.

Certainly, whenever the v.Nu developers decide it's time for a new 
release:

https://github.com/validator/validator/releases

If that's not what you meant by "when": for details on when, during the 
build process, the missing files are generated, see the source of 
build.py.

Where: that depends on what you mean by "where", and probably not for the 
facetious reasons you're imagining ;-).

All of the schema files are delivered in the .jar (or .war; but I've been 
using the .jar) in one "flat" directory (with no subdirectories):

nu/validator/localentities/files/

That directory contains a file named entitymap. Each line of that file 
maps a file name in that directory to a URI. Here is an example line for a 
schema file:

http://s.validator.nu/html5/block.rnc  schema_html5_block_rnc

The extension-less file names are an underscore-delimited concatenation of 
the directory path, file name, and extension of the corresponding source 
file from the repo (or a similar-looking confection, for files that are 
created during the build).

So the answer to "where" has more to do with those internal v.Nu schema 
URIs than the actual "physical" location (directory path) of the files in 
the generated .jar.

In terms of those URIs, the missing files are generated in the html5 
directory.

One file, rdf.rnc is moved from the repo .drivers directory to the "build 
only" rdf directory.

There are other differences, too.

For more details, you can perform your own comparison by following the 
steps in the readme at:

https://github.com/unsoup/validator#comparing-the-source-and-distributed-schemas

Or ask me, and I'll send you a detailed report from, say, WinMerge (what I 
typically use), or your free diff tool of choice.

Graham

Fundi Software Pty Ltd  2016  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

Re: Using Emacs nXML mode to validate XHTML5 using the v.Nu schemas: support for HTTP-based schema URI?

[Graham Hannington]

Hi Stefan,

To recap:

> Some schemas in the v.Nu GitHub repo [...] refer to file paths that do 
not exist in the repo. The paths exist only in the context of [...] 
vnu.jar
> These nonexistent paths prevent the schemas being usable directly from 
the v.Nu repo

... or even - and I infer from your email that you have experienced this 
issue - being usable when downloaded from the v.Nu repo.

The v.Nu source architecture and build process could be changed to allow 
the schemas to be usable directly from the source repo. Anything is 
possible. Given time, I might be able to do it myself; certainly, I could 
reorganize the schemas, and with assistance from the v.Nu developers - in 
particular, those developers with Java experience - integrate those 
changes into v.Nu. But I don't have that time: I have a day job.

More importantly, Mike(tm) Smith, currently the most active v.Nu 
developer, recently made this comment in reply to an issue I created on 
the subject:

 > I understand what you want and why but I don’t plan to provide myself 
from this repo/project a .zip release with the relaxng files, nor a readme 
on how to use the files outside the context of the checker.
> ...
> it would frankly take me a lot of time myself to go back and look at the 
structure of it all an figure out how to make a standalone set of static 
files for it (rather then the generated files the checker itself uses)

(For the complete text, see 
https://github.com/validator/validator/issues/251.)

... which is what prompted me to create a repo to provide those things at:

https://github.com/unsoup/validator

I frankly hope that the need for such a resource is fleeting. I would 
prefer the "canonical" XHTML5 schema, as Mr Smith himself describes it, to 
be completely usable directly from its GitHub repo.

However, achieving that goal will take more than time and effort. It will 
take political willpower to decide to change the source architecture and 
build process; and, yes, possibly funding, too (I'm not looking for this; 
while I'm interested in this work, I have a job that I want to keep).

But I'm a randomprole (my compound coinage :-) ). If you and other 
luminaries such as Mr James Clark think this is a worthwhile goal, then I 
invite you to raise the idea with WHATWG, the W3C, and perhaps also the 
Mozilla Foundation and the Mozilla Corporation (who funded the development 
of v.Nu). Besides, I think I've bugged Mr Smith enough for now.

Another comment (on the same issue) from Mr Smith:

> [The v.Nu GitHub repo is] the only canonical source for the XHTML5 
schema.
> But as I alluded to in previous comments, it’s not the goal for it to be 
that, but instead basically just a consequence of the fact that the schema 
is a necessary component of the code for the HTML checker under its 
current architecture.

What I get from that is: if the schema ceases to be a necessary component 
of the code for the HTML checker, there goes your canonical source for the 
XHTML5 schema. I have no idea whether there are any plans for that to 
happen, but still: he's thought about it.

Finally, given this from the WHATWG FAQ:

> Going forward, the WHATWG is just working on "HTML", without worrying 
about version numbers.

and even this comment from Mr Smith:

> the schema is not official in any way. It is not a standard. The only 
standard for HTML is the spec itself, and the only standard formalism for 
HTML is the prose of the the HTML Standard. The schema is an 
implementation (and of just a part of it).

I still look at those v.Nu GitHub repo release tag names such as 16.3.3 
(and even the commit ID), stroke my nonexistent beard, and think: if 
someone did want to refer to... but no, I will not finish that thought in 
writing. I hear the sound of jackboots.

I'm signing off for the night, probably to dream about Splunk (nothing to 
do with this email), but also a website that displays two columns, side by 
side, populated by commit histories via AJAX requests to the GitHub API:

- One column showing the history of changes to the v.Nu schema files
- The other column showing the history of changes to (as Mr Smith puts it) 
the prose of the HTML spec

Both columns linked to a common filter based on date range and search 
string. (When did some new markup first appear; in the spec, in the v.Nu 
schemas? Maybe even: staggered date ranges between columns.)

Now I'm imagining those changes charted in a Splunk dashboard... then 
Horton the elephant arrives and starts spawning *hive-mind 
number-crunching clones*... I really need to sleep ;-).

Graham

Fundi Software Pty Ltd  2016  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

Re: Using Emacs nXML mode to validate XHTML5 using the v.Nu schemas: support for HTTP-based schema URI?

[Graham Hannington]

I've uploaded to GitHub that "Get v.Nu schemas" Windows PowerShell script 
I mentioned:

https://github.com/unsoup/validator/blob/gh-pages/tools/Get-vnu-Schemas.ps1

I understand that PowerShell might not be your choice of scripting 
language.

Still, you might be interested in the logic inside the ForEach loop that 
iterates over the entitymap file and extracts the schemas from their 
"flat" directory in the .jar to a directory structure that matches the 
internal v.Nu URIs.

Graham

Fundi Software Pty Ltd  2016  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

Re: Using Emacs nXML mode to validate XHTML5 using the v.Nu schemas: support for HTTP-based schema URI?

[Stefan Monnier]

> I've uploaded to GitHub that "Get v.Nu schemas" Windows PowerShell script 

Thanks.


        Stefan

On-the-fly validation of (X)HTML5 using the v.Nu REST API

[Graham Hannington]

I've been playing with the schemas from v.Nu in various tools and editors, 
including Emacs. The implementation-specific nature of the required 
datatype library irks me; in some cases, it's proven to be a barrier, or 
at least a nuisance.

I decided to experiment with the v.Nu REST API (HTTP interface):

https://github.com/validator/validator/wiki/Service:-Input:-POST-body

No need for an external datatype library, because it's bound into v.Nu. 
You get the full benefit of v.Nu validation (including Schematron), not 
just the RELAX NG schemas. And, as long as the HTTP interface is still 
supported, it doesn't matter if the underlying validation technology used 
by v.Nu moves away from a RELAX NG schemas.

Based on those experiments, I have developed and published a linter 
provider for the Atom editor that uses the v.Nu REST API:

https://atom.io/packages/linter-vnu

If you're interested in editing (X)HTML, watch the animated GIF on that 
page showing on-the-fly validation.

The same technique could be used for Emacs. Just a thought.

Graham Hannington

Fundi Software Pty Ltd  2016  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

Re: On-the-fly validation of (X)HTML5 using the v.Nu REST API

[Emanuel Berg]

"Graham Hannington" <graham_hannington@fundi.com.au>
writes:

> If you're interested in editing (X)HTML, watch the
> animated GIF on that page showing
> on-the-fly validation.

I haven't heard of XHTML for years. And what I heard
then, the W3C disencouraged the use of it in favor
of HTML5.

Also, how would one benefit from on-the-fly
validation? Isn't it just static documents like plain
HTML? I think it is better to validate once, when
done. More mindful, and besides - don't you have to
really stink to do errors all the time *with HTML*?!

As always, just because it is possible, question
remains, is it also a good idea?

For HTML, I use validate(1), the "Offline HTMLHelp.com
Validator", which is in the Debian repos pack
wdg-html-validator. Worth checking out!

-- 
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
                   - so far: 20 Blogomatic articles -                   

Re: On-the-fly validation of (X)HTML5 using the v.Nu REST API

[Stefan Monnier]

> As always, just because it is possible, question
> remains, is it also a good idea?

I use nxml's on-the-fly validation, for two reasons:
- I find it convenient.
- It provides the data for completion, which I find very handy.


        Stefan

Re: On-the-fly validation of (X)HTML5 using the v.Nu REST API

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> As always, just because it is possible, question
>> remains, is it also a good idea?
>
> I use nxml's on-the-fly validation, for two reasons:
> - I find it convenient. - It provides the data for
> completion, which I find very handy.

You mean for the XML part? OK, I suppose that's the
"X" in XHTML...

-- 
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
                   - so far: 20 Blogomatic articles -                   

Re: On-the-fly validation of (X)HTML5 using the v.Nu REST API

[Graham Hannington]

Hi Emanuel,

Re:

> I haven't heard of XHTML for years.

XHTML lives on as the XML serialization of HTML5.

From the current W3C Editor's draft of HTML 5.1, and also the WHATWG HTML 
Living Standard:

> HTML vs XHTML
> This specification defines an abstract language ...
> There are various concrete syntaxes that can be used to transmit 
resources that use this abstract language,
> two of which are defined in this specification. ...
> The first such concrete syntax is the HTML syntax.
> The second concrete syntax is the XHTML syntax, which is an application 
of XML.

at:

http://w3c.github.io/html/introduction.html#html-vs-xhtml

and:

https://html.spec.whatwg.org/multipage/introduction.html#html-vs-xhtml

Note this from WHATWG:

> For a number of years, both [W3C and WHATWG] groups then worked 
together.
> In 2011, however, the groups came to the conclusion that they had 
different goals:
> the W3C wanted to publish a "finished" version of "HTML5",
> while the WHATWG wanted to continue working on a Living Standard for 
HTML,
> continuously maintaining the specification rather than freezing it in a 
state with known problems,
> and adding new features as needed to evolve the platform.
>
> Since then, the WHATWG has been working on this specification (amongst 
others),
> and the W3C has been copying fixes made by the WHATWG into their fork of 
the document
> (which also has other changes).

at:

https://html.spec.whatwg.org/multipage/introduction.html#history-2

Re:

> And what I heard then, the W3C disencouraged the use of it in favor of 
HTML5.

Could you please point me to the URL of a web page where the W3C does 
this?

Re:

> how would one benefit from on-the-fly validation?

One example: validation errors are caught as you type them, so you don't 
end up with a document that is riddled with errors that you only find out 
about when you save.

This also depends on personal preference and particular circumstances: 
sometimes I prefer on-the-fly, sometimes not.

With that Atom package I mentioned, you can choose to validate either on 
the fly or only when you save.

Either way - on the fly or only when you save - validation is integrated 
with editing: the editor highlights the validation errors in situ. You 
don't have to run a validation report outside of the editor.

Re:

> For HTML, I use validate(1), the "Offline HTMLHelp.com Validator", which 
is in the Debian repos pack wdg-html-validator. Worth checking out!

If I go to:

http://www.htmlhelp.com/tools/validator/direct.html.en

and then replace the <!DOCTYPE ...> with:

<!DOCTYPE html>

the validator responds:

> Document Checked
> Character encoding: ISO-8859-1
> Level of HTML: Unknown
>
> Errors and Warnings
> Line 1, character 15:
> <!DOCTYPE html>
> Error: no internal or external document type declaration subset; will 
parse without validation

How do you (by which I mean: you, Emanuel) validate HTML5?

Regards,
Graham Hannington

Fundi Software Pty Ltd  2016  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

Re: On-the-fly validation of (X)HTML5 using the v.Nu REST API

[Graham Hannington]

> - It provides the data for completion, which I find very handy.

I'm working up the courage to create an issue for v.Nu that asks for 
completion candidates via its REST API. I can anticipate one (reasonable) 
response might be "show me the code" (patch) :-). Another (polite) 
response might be "out of scope".

Graham

Fundi Software Pty Ltd  2016  ABN 89 009 120 290


This message has been scanned for malware by Websense. www.websense.com

Re: On-the-fly validation of (X)HTML5 using the v.Nu REST API

[Stefan Monnier]

>> - It provides the data for completion, which I find very handy.
> I'm working up the courage to create an issue for v.Nu that asks for 
> completion candidates via its REST API. I can anticipate one (reasonable) 
> response might be "show me the code" (patch) :-). Another (polite) 
> response might be "out of scope".

Depending on how the REST API works, it might be easy to write a bit of
Elisp which provides a hypothetical completion command using an
extension of the REST API.


        Stefan

Re: On-the-fly validation of (X)HTML5 using the v.Nu REST API

[Emanuel Berg]

"Graham Hannington" <graham_hannington@fundi.com.au>
writes:

> Re:

Some unrelated formalia:

It is not necessary to put Re: before citations.
Because that is the whole idea with the angle bracket
syntax! I suspect you did it because you also used the
same syntax for *quotes*, i.e. material that didn't
appear in this thread before. There is a better way to
do that. Either just yank the quotes. Or if you want
to make them look good, indent the whole block, like
this:

    Some unrelated formalia. It is not necessary to
    put Re: before citations. Because that is the
    idea. I suspect you did it because you also used
    the same syntax for *quotes*, i.e. material that
    didn't appear in this thread. There is a better
    way to do that. Either just yank the quotes. Or if
    you want to make them look good, indent the whole
    block, like this:

I do that with a region and `C-u C-x TAB'.

With Gnus, and possibly other clients, it is possible
to hide citations (but they can be expanded):

    (setq gnus-treat-hide-citation t)

It is a very practical thing especially as messages
are exchanged pretty quickly so typically you remember
what you already read.

*But*, if you interchange them and use angle brackets
for quotes, this is what happens:

    http://user.it.uu.se/~embe8573/figures/gnus/gnus-hidden-quotes.png

The quotes are hidden as well!

Second, consider putting your signature under two
dashes, a space, and a newline, e.g., using C syntax
"-- \nJoe Hacker". Otherwise, again,
`gnus-article-hide-signature' and the corresponding
setting for other clients won't work.

This is described in: RFC 3676, section 4.3 [1]

> Could you please point me to the URL of a web page
> where the W3C does this?

    In 2009, the W3C allowed the
    XHTML 2 Working Group's charter to expire,
    acknowledging that HTML5 would be the sole
    next-generation HTML standard, including both XML
    and non-XML serializations. Of the two
    serializations, the W3C suggests that most authors
    use the HTML syntax, rather than the XHTML
    syntax. [2]

>> how would one benefit from on-the-fly validation?
>
> One example: validation errors are caught as you
> type them, so you don't end up with a document that
> is riddled with errors that you only find out about
> when you save.

Right, I did XML only once or twice so I don't know
how error-prone it is or how dependent the user is on
auto-completion. When I said nobody would benefit from
it, I was thinking HTML only, so I half-retract from
that statement.

I remember doing Visual Basic 5.0 as a kid. The
"GUI GUI" was, I have to give them, great, if you are
into making and using GUIs, that is. But it was
actually the opposite of MVC and it was enough to
place just a couple of buttons on the canvas to get it
all out of hand! So when you were writing code, you'd
type one letter and it'd immediately suggested several
hundred alternatives! So you'd use Hungarian notation
with the names and hopefully get it right with luck,
skill, and patience. (Or as my mother called
it: frustration.)

Perhaps using XML with thousands of objects and data
items is similar to that?

... eh :)

> This also depends on personal preference and
> particular circumstances

Yes.

> You don't have to run a validation report outside of
> the editor.

Good, but with Emacs you can run anything outside or
inside the editor, *from* the editor. (At least if you
by "inside" mean getting the result in an Emacs
buffer. With programming, you can get total
"insidness", of course.)

> How do you (by which I mean: you, Emanuel)
> validate HTML5?

This is the most advanced HTML I did validate:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
              "http://www.w3.org/TR/html4/strict.dtd">

The tool I mentioned, validate(1), doesn't mention
HTML5 in its manpage, but I found this:

    --xml
      Indicate that the documents to be validated are
      XML documents. Known document types, such as
      HTML 4.01 and XHTML 1.0, are automatically
      handled by "validate". For unknown document
      types, "validate" will assume XHTML/XML if this
      option is specified and HTML/SGML otherwise.

and this:

    --[no]emacs
        (don't) use an output format intended
        for parsing by (X)Emacs, autodetected.

Nothing I felt the need to try, tho.

[1] http://www.ietf.org/rfc/rfc3676.txt
[2] https://en.wikipedia.org/w/index.php?title=xhtml&printable=yes

-- 
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
                   - so far: 20 Blogomatic articles -                   

Re: On-the-fly validation of (X)HTML5 using the v.Nu REST API

[Emanuel Berg]

"Graham Hannington" <graham_hannington@fundi.com.au>
writes:

> I'm working up the courage to create an issue ...

Do it!

> Another (polite) response might be "out of scope".

Oh, yeah? So red-tapist, condescending exclusion is
more polite than honest discussion? Actually: less.

-- 
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
                   - so far: 20 Blogomatic articles -