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

On Tue, 27 Jan 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > ...
> > That would help if the audience was limited to producers, yes. If
> > implementors are still included, though, I don't think it makes sense to
> > leave the implementation criteria undefined.
> > ...
> 
> I guess we need to clarify what "implementors" refers to here. All of 
> them? Implementors of producers?

The spec is pretty clear: "implementors of tools that are intended to 
conform to this specification".


On Wed, 28 Jan 2009, Michael(tm) Smith wrote:
> Ian Hickson <ian@hixie.ch>, 2009-01-28 01:04 +0000:
> >
> > He has, according to what he has said, merely started writing the 
> > first part of a document with the same audience as the HTML5 draft.
> 
> I've never said that the document has the same audience as the HTML5 
> draft. What I did was to take a portion of the text from the Audience 
> section of the HTML5 and copy it into my draft, changing one instance of 
> the word "authors" to "producers".

(Producers is defined as a superset of authors earlier in the draft.)


> 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?

Notwithstanding the few comments to the contrary on this mailing list 
(from Julian in particular), as far as I can tell the current draft, with 
the direction it is headed in, isn't the most useful it could be for any 
constituency of any magnitude.

For example, for Web authors, IMHO, we need a reference guide, and we need 
topical tutorials. It doesn't have to be normative, with all the minutiae 
described in formalisms and so on. It does need the APIs, especially for 
elements like <video> and <canvas>.

Feedback in response to Steve's twitter:

  Fyrd: I see both the importance in having the fullblown spec as well as 
  a guide that tells authors when/where to use which element
   -- http://twitter.com/Fyrd/statuses/1155264330

  Rits: having an auto-generated 'author spec' extraction from the big one 
  might be very useful
   -- http://twitter.com/Rits/statuses/1155261206

  gezlemon: I think it makes sense to have a version for web authors
   -- http://twitter.com/gezlemon/statuses/1154971666

I agree entirely with this feedback, and it is representative of the 
feedback I've seen in other forums. It doesn't describe a normative, 
formalism-based, API-free specification such as the current draft.

These comments do, incidentally, describe what I have been saying I plan 
to do with HTML5, namely provide a filter that hides the implementation 
conformance requirements; and they also match a reference guide such as 
what Lachlan is writing.


> > 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.


> 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.

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.


> 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). 


> or it could be a part of a CMS that just needs to generate valid HTML 
> output, but doesn't itself need to parse it.

Indeed, that is also covered by the statement.


> 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. :-)


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 28 January 2009 22:38:52 UTC