Which types for representing HTML documents ?

Which types for representing HTML documents ?

[Sébastien Hinderer]

Dear all,

According to you, how could an HTML document best be represented in
OCaml ?
In particular: would you rather use classes or records, polymorphic
variants or normal constructors ?

There are attributes which can occur in several elements, such as id,
class... How shold these be represented ?
Should the types reflect the differences between inline elements and
other types of elements ?

Many thanks in advance for your suggestions,
Sébastien.

Re: [Caml-list] Which types for representing HTML documents ?

[Gabriel Kerneis]

On Mon, Jun 08, 2009 at 06:59:57AM +0200, Sébastien Hinderer wrote:
> According to you, how could an HTML document best be represented in
> OCaml ?

http://ocsigen.org/docu/1.2.0/XHTML.M.html

The whole website is worth reading if you're interested in web
programing using Ocaml.

Regards,
-- 
Gabriel Kerneis

Re: [Caml-list] Which types for representing HTML documents ?

[Richard Jones]

On Mon, Jun 08, 2009 at 06:59:57AM +0200, Sébastien Hinderer wrote:
> Dear all,
> 
> According to you, how could an HTML document best be represented in
> OCaml ?
> In particular: would you rather use classes or records, polymorphic
> variants or normal constructors ?

CDuce is worth considering:

http://www.cduce.org/examples.html

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Which types for representing HTML documents ?

[Martin Jambon]

Sébastien Hinderer wrote:
> Dear all,
> 
> According to you, how could an HTML document best be represented in
> OCaml ?

Ocamlnet's Nethtml works fine for parsing:

type document =
    Element of
      (string * (string * string) list *
       Nethtml.document list)
  | Data of string


If your goal is to interpret arbitrary web pages, you have to allow all kinds
of standard or non-standard elements and attributes anywhere in the document.

If you are creating HTML documents, beware that you can't embed Flash objects
using standard HTML.  I'm not even speaking of javascript happily manipulating
the DOM tree with little restrictions.


Personally I use text templates and validate web pages once they are in my
browser (using the shortcut to validator.w3.org that opera provides).  For
javascript-generated nodes, I just check that it works in various browsers
(the firefox "View source chart" extension is useful for debugging the DOM tree).


I do not suffer at all from the absence of static type-checking of the HTML
tree.  I imagine that the reasons for this are:

* HTML is the final product and is trivial to debug (no need to printf
everything since everything is already printed...)

* There are no complicated conditionals that would leave certain parts of the
code untested for a long time.

* Mainstream web browsers are very tolerant.  Small accidental deviations from
the strict W3C standards usually have no visible effect.



> In particular: would you rather use classes or records, polymorphic
> variants or normal constructors ?
> 
> There are attributes which can occur in several elements, such as id,
> class... How shold these be represented ?
> Should the types reflect the differences between inline elements and
> other types of elements ?


I know this is going to annoy a lot of people on that list, but this feels
very academic to me :-)



Martin

-- 
http://mjambon.com/