Re: Encoding of site structure ...

 --- David Woolley <david@djwhome.demon.co.uk> skrev:
> 

> Coming back to HTML, there are I think two different
> issues here.  One is
> the treatment of a super-node as a single entity for
> management.  That seems
> to me to be an authoring tool job, and I believe
> that, for example, the
> non-loss leader versions of Front Page provide site
> network diagrams
> for the developer.  Whilst there is a case for
> standardisation here,
> the pressures for it are less, so the advantages to
> tool developers of
> a supplier lock in from a proprietory format tend to
> dominate.

If the site and its structure is defined by an
authoring tool in its own non-standard format, and the
authoring tool does some smart things with this, like
putting a navigation bar and a site header in each
page, then much of the data is lost when serving the
pages on the web, and instead of the original site
definition, which could be used and displayed in lots
of ways, we have the static navigation bars in the
pages, which are far less useful, and don't express
the same meaning (there is no difference in HTML
between a navigational hyperlink and a "normal" one).
And I don't think it should be necessary to use a
fancy authoring tool with preprocessing facilities (or
server-side processing) to write simple sites and
pages which do not actually need it.

> The other issue was standard elements on each page
> (forms in PDF).  This
> can be done server side (although the normal result
> is non-cacheable pages,
> although this is not inevitable).  This wasn't in
> early HTML as it was
> intended that people not be trapped within a super
> node controlled by a
> single manager.  However, SGML, on which HTML is
> based, and XML both
> implement this capability, in the form of external
> entities.  No HTML
> browser supports this, and I don't think that there
> are any validating
> XML browsers, which would be necessary to do this.

What are these "external entities"?
 
> > written in a way so that UAs doesn't have to read
> them
> > and show at least the navigation (and preferably
> also
> > other site-wide content, such as headers), then we
> > still have to mess up the pages with including
> this in
> > them all to make sure they are accessible to all.
> 
> This sort of thing was in very early in the form of
> link elements.  I
> suspect the reason why link elements were largely
> ignored, or replaced
> by non-linking ones, like meta, is that designers do
> not want the 
> browser to control the presentation of such elements
> of the design.
> However, note that Lynx and recent Mozillas will
> provide access to
> link elements providing forward, next, up, down,
> index, ... type
> links.  Of course, very few authors realise that
> these existed
> from almost the beginning.

There are some significant differences between the
HTML link element and what I am talking about:
- The link elements are specified in each page. This
makes authoring more difficult, and the site structure
is split up and partly defined in many pages, probably
redefining links many times.
- When making a navigation bar from link elements,
only those pages that are linked to directly from the
displayed page are accessible. Displaying a complete
navigation tree is impossible.
- User agents _may_ display link elements for
navigation. This means that the links has to be
included in the document content too.

And why does it have to be impossible for the authors
to control the presentation of such navigation bars?
Does the content of the pages _have_ to be the only
thing for which authors may provide style sheets?



______________________________________________________
Få den nye Yahoo! Messenger på http://no.messenger.yahoo.com/
Nye ikoner og bakgrunner, webkamera med superkvalitet og dobbelt så morsom

Received on Saturday, 8 March 2003 11:29:28 UTC