W3C home > Mailing lists > Public > public-html-xml@w3.org > January 2011

Re: Use cases

From: James Clark <jjc@jclark.com>
Date: Wed, 5 Jan 2011 08:04:29 +0700
Message-ID: <AANLkTi==B2Msjo1xgsxxY9KxXXccvOviJuA9b6LEtVJh@mail.gmail.com>
To: public-html-xml@w3.org
1. One use case that is important to me is using a schema-driven XML
authoring tool to create HTML5 in the HTML syntax.  In particular, I would
like to be able to use a tool like nxml-mode, which is schema-aware but
exposes the syntax of the document, rather than working purely on a tree.

I want to do this so that I can at the same time:

- use a customized schema to constrain documents to a subset of HTML5; this
is not just a matter of using only a subset of HTML5 elements and
attributes, but also things like constraining the values of "class"
attributes and constraining structure (for example, enforcing the use of
<section> elements to to indicate document structure explicitly)

- create a document that is well-formed XML (so that XML tools can be used
on it)

- create a document that is a valid HTML5 document in the HTML syntax, or a
fragment of such a document (so I can eg view it directly in a browser, or
combine it with other HTML fragments using non-XML-aware tools)

Although I can already do this, the experience is not as good as it could
be, because my document must follow a whole bunch of detailed restrictions
that are not enforced by the authoring tool, because they are not
expressible in a schema and not required by XML well-formedness.

This is one of the scenarios that motivates my interest an XML subset.  The
idea would be that the authoring tool would add support for this subset.
 For example, perhaps there would be an annotation in the schema that the
tool would use to tell it to use this subset for a document.  Ideally use of
the subset together with conformance to the schema would be enough to
guarantee HTML5 validity.  This ideal is unlike to be 100% achievable, but
it's not a binary thing: the closer one can get to this ideal, the better.
Also, ideally, the XML subset should be useful to people who are looking for
something like XML, but radically simpler.

2. Other use cases don't need to involve tools at all.  I am not sure if
everybody would call these use-cases, but they are scenarios that I think
are relevant to the design.

(a) A non-expert user writes HTML5 in Notepad.  He has some modest
familiarity with HTML4 and with XML.  He has heard that HTML5 supports the
XML empty element syntax.  So he decides to write

  <script src="foo.js"/>

and is rather surprised to find it doesn't work.

(b) A scripting language user is writing a little script to generate some
HTML5 from a tree of elements.  He does the simplest thing that (he thinks)
could possibly work and generates a start-tag and end-tag for every element
(he's not too sure about the void elements). He tests this lightly by
loading it in his browser, and is delighted to finds that <img> works just
find with an end-tag.  He puts it into production and is puzzled to find
strange vertical spacing issues around <br> elements, which he fixes with
some CSS.

3. A user has a tool that generates SVG or MathML. Both SVG and MathML have
the ability to embed foreign XML from arbitrary XML vocabularies. The tool
takes advantage of this (with or without the user's knowledge).  The user
then copy-and-pastes the generated SVG or MathML into an HTML5 document
(perhaps performing some rudimentary fixup of the start of document, like
removing the XML and DOCTYPE declaration).   They want the resulting
composite document to be valid HTML5.

James
Received on Wednesday, 5 January 2011 01:05:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 5 January 2011 01:05:52 GMT