W3C home > Mailing lists > Public > www-html@w3.org > February 2000

RE: Seperating Document Content from Structure (was RE: inline CS S - score so far)

From: Patrice Calve <patrice.calve@cactuscom.ca>
Date: Wed, 23 Feb 2000 13:06:47 -0500
Message-ID: <D4E29E4CDBEFD111AB9A00400522C9E23BBD33@florentine.cactuscom.com>
To: www-html@w3.org


> -----Original Message-----
> From: David Wagner [mailto:dwagner@kevric.com]
> Sent: Wednesday, February 23, 2000 12:37
> To: www-html@w3.org
> Subject: Seperating Document Content from Structure (was RE: 
> inline CSS
> - score so far)
> 
> 
> > Murray.Altheim wrote:
> >
> > David Wagner wrote:
> > [...]
> > > One more question reaching further into the future: we 
> are dutifully
> > > seperating style from structure and content.  What about 
> seperating
> > > document content from its structure?  Any plans for this?
> >
> > The role of markup is to perform this task. I don't see how you'd
> > separate the markup from the document content, or why you'd want to.
> > Perhaps you could clarify?
> >
> > Murray
> 
> I haven't thought this through in a rigorous manner, but the 
> concept has
> been
> tickling me since most of the HTML development at my paying 
> jobs has been to
> present content from a database, and it looks like many other 
> websites use
> HTML to structure and present external data as well.  I threw
> together a straw  document fragment below, which would extract from a
> database the element content.  The HTML provides the structure of the
> document,
> and body elements may be empty or contain other elements, but may not
> contain content.  The content comes from a <content> element 
> in the head (as
> does
> styling now), or from files, parts of files, database 
> queries, or any other
> source of the appropriate type of data.


Separating the content (data) with the structure has been a great source for
discussion in the company.

95% of the Web sites created by the company rely on a database source and an
HTML template (Web Applications).

The earlier approach was to have an artist/designer creat a dummy web page
in HTML, programmers converted it to ASP (microsoft IIS) and probably use
DLLs for managing the data, depending on the size and speed of the site.

As you can imagine, if you change the look of one page, you can't simply ask
the artist to poke around in the DLLs and the ASP files.  Big Problem:  How
to merge a new look with the existing code.

The last few Web Apps created by our team uses XML and XSL.  Since old
browsers need to be supported, we can't rely on the Cascading Style Sheets
for some look.  The mariage of XML and XSL is done by the DOM dll from
Microsoft.  This DLL loads the XML and the XSL and produce a merged HTML
file.  Of course, this new DOM is already out dated, but it answers most of
our questions.  Another problem is the convertion time needed to read the
XML and XSL, interpret, merge, and output, at each request.

We still have the problem of teaching the artist to play around with XSL
syntax, but at least now, we can target a different XSL for different
browsers which is another problem.

The Next Generation of MS Visual Studio is suppose to tackle this
Structure/content issue, still waiting.

Visual Basic's WebClasses was a step towards this goal, but wasn't very easy
or fast (version 6).

This merger of structure and data is of greater importance with the advent
of palm tops and PDAs.  How do you show the content of web page on a 25x10
pixel display?  This is the job of the XSL.  The data is the same, it's just
displayed differently than on a 1600x1280 screen, or a a brail display, etc.

Pat
Hull, Quebec, Canada
Received on Wednesday, 23 February 2000 13:09:06 GMT

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