Re: Who is the Intended Audience of the Markup Spec Proposal?

Ian Hickson <ian@hixie.ch>, 2009-01-28 22:38 +0000:
> On Wed, 28 Jan 2009, Michael(tm) Smith wrote:
> > Anyway, from the fact that it has a portion of the same audience 
> > statement as the HTML5 draft, it does not necessarily follow that my 
> > draft has the same audience as the HTML5 draft -- because I think the 
> > audience statement above is fairly general, and could be put into just 
> > about any spec that defines some kind of "document".
> 
> If you don't think that this audience statement accurately and precisely 
> reflects the audience you are targetting, then could I please ask you to 
> make it more precise?

I don't think that text any less accurately and precisely reflects
that audience the draft is targeting than the same text in the
HTML5 draft accurately and precisely reflect the audience it is
targeting.

If it's not clear from what I've said thus far, I don't think an
explicit statement of the intended audience is necessary in either
draft, and quite possibly not even helpful -- because, for one
thing, it provides a convenient opportunity to drag on with
unproductive discussions just like this one. 

That's why I didn't put an explicit statement of the audience in
the spec from the beginning. And why I'd really like to not waste
further time playing the game we're playing right now.

As I've said in so many words already, the audience for this draft
is producers of HTML documents who want to know what the
definition of a conformant document is. You and others have said
that you don't think the draft actually meets the needs of that
audience, and I have noted that you've said that and I am quite
willing to add a statement to the Status section making it very
clear that a number of members of the group have judged that it
doesn't meet the needs of that audience.

> > > Such a draft would have to include all manner of implementation 
> > > conformance criteria, DOM APIs, parser rules, etc.
> > 
> > I don't think that's a point of fact, and I don't think it necessarily 
> > follows at all from the audience statement above.
> 
> Unless you have a novel interpretation of the term "implementor", 
> implementation requirements are rather required for said implementors.

A spec that defines DOM APIs and parser rules certainly needs to
provide implementation requirements for DOM and parser
implementors. This draft does not define those things, so it's not
the place to provide implementation requirements for them.

There is clearly a whole range of possible implementors of tools
that do something with HTML. Some tools focus mostly on consuming
HTML and doing something useful with it, snd some tools focus
simply on producing HTML output.

An implementor of a script of some kind whose purpose is, say,
just to programatically produce/generate HTML output is certainly
a different kind of implementor than, say, a browser implementor
-- but still an implementor. And all that particular kind of
implementor would want to need to know for that case is what a
conformant HTML document looks like, so that he or she can ensure
that the script produces HTML that conforms to that definition.

> > The audience statement above does not qualify at all what type of 
> > implementors or tools it is referring to.
> 
> Yes it does, it says "implementors of tools that are intended to conform 
> to this specification". That's a broad description that includes authoring 
> tools, conformance checkers, command-line tools, browsers, etc.

And my draft is scoped to address a very specific need of all
those implementors: providing them with the information they need
to determine whether a particular document instance is a
conformant HTML document or not.

> If you didn't mean to include "tools that are intended to conform to this 
> specification", then that's fine, but please adjust the audience statement 
> accordingly.

OK, I've revised it to this:

  This specification is intended for producers of documents
  intended to conform to the requirements it describes, and
  individuals wishing to establish the correctness of documents
  with respect to the requirements it describes.

> > A "tool" could be something as simple as a plug-in for Vim or Emacs that 
> > enables context-sensitive editing of HTML documents,
> 
> Indeed, the audience statement covers these (and that's one reason you 
> need the parser spec in your draft to address your audience's needs). 

No, of course it's not. If all I want to do is write a script that
spits out HTML, I don't need to know nor care how to implement an
HTML parser.

> > All that said, I don't think it would be a problem even if it stated 
> > that it did have the same audience as the HTML5 draft. Having the same 
> > audience would not then necessarily require it to contain details about 
> > DOM APIs, parser rules, or many of the other things that the HTML5 draft 
> > has -- because it's explicitly not intended to cover everything that 
> > audience would need to know.
> 
> Intentionally being incomplete is not a excuse for being incomplete. :-)

Note that I didn't use the word "incomplete", and it's not
intentionally incomplete. The audience reference above was to the
larger set of audiences for the HTML5 draft, not to the specific
audience for this draft. For the audience who wants a definition
of what a conformant document is, I don't intend this spec to be
incomplete.

> I'm not arguing against going to FPWD. However, in its current state, I 
> _would_ argue against it going to LC.

Understood

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/

Received on Thursday, 29 January 2009 08:02:06 UTC