W3C home > Mailing lists > Public > www-html@w3.org > December 2003

Re: Structure vs Semantics

From: Ernest Cline <ernestcline@mindspring.com>
Date: Tue, 9 Dec 2003 16:37:21 -0500
Message-ID: <410-220031229213721531@mindspring.com>
To: "Lachlan Hunt" <lhunt07@netscape.net>
Cc: www-html@w3.org




> [Original Message]
> From: Lachlan Hunt <lhunt07@netscape.net>
> To: Jewett, Jim J <jim.jewett@eds.com>
> Cc: <www-html@w3.org>
> Date: 12/9/2003 8:22:20 AM
> Subject: Re: Structure vs Semantics
>
>
> Jewett, Jim J wrote:
>
> >Structure is important to the extent that it helps 
> >with semantics.  Nesting is important.  Order is
> >sometimes important.
> >
>   Absolutely Correct!!!
>
> >But why is block vs inline important?  
> >...
> >The conceptual "size" of the contained information 
> >is truly important.  
> >
> >Some element types (such as <strong>) are large 
> >enough to contain subelements, but not large 
> >enough to stand on their own.  Since they can't 
> >stand on their own, they shouldn't contain 
> >anything that does - or even could.
> >
> ><snip>about limiting href to small, basically inline elements</snip>
> 
>   I think this possibility is the more accurate than the second one you 
> provided.  I'll leave the discussion of href for now, and I'll focus 
> more on the structure and semantics issues.
>
>   In light of this discussion of removing the presentational distinction 
> between block and inline, I have looked at the elements, and reorganised 
> them into new structural modules, which are not linked to their 
> presentation in any way.  This is far from perfect, but I believe it is 
> a *good start* to removing the distinction.  The content models are 
> probably the biggest problem, but I've done my best, without spending a 
> very long time analysing every single element.

<snip>proposal to reformulate the Block and Inline Modules into three
modules with the new module to merge elements such as "quote"
and "blockquote" into a single element.</snip>

The problem is that with the structure of XML, it is impossible to allow
<a><b/></a> and <b><c/></b> while banning <a><b><c/></b></a>.
(At least via an XML DTD there is no way to do this. Does XML
Schema or Relax NG provide a mechanism to do this?)

Thus, with the proposed model we would have to accept
<em><quote><div/></quote></em> even tho we
don't want <em><div/></em>.

Note however that such exclusions can be specified in SGML.
It looks like to enforce the block/inline distinction while providing
the desired generality we have several unpalatable choices:
1) Accept that we will need a number of doubled elements
such as <quote/> and <blockquote/> to enforce the distinction
even tho semantically they are the same.
2) Instead of producing XHTML 2, we go back to SGML and
produce HTML 5 instead.
3) Push for a new version of XML that does allow for  these
sorts of restrictions to be enforced and then base XHTML
on the new XML version.
4) Totally revise what we are working on to eliminate
the block/inline distinction and thus make it so different from
existing (X)HTML that it could not honestly be called XHTML,
but should be given a new name.such as XHT*ML
(Xml HyoerText ** Markup Language).
[Fill in * and ** with appropriate officious sounding term
such as S and  Semantic or Structured or Supercilious)
Received on Tuesday, 9 December 2003 16:37:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:59 GMT