OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Separating content from presentation

It's an old hangover from The SGML Way.  It was adapted as a
sales slogan for XML.   Nothing in XML presupposes that
separation.  It is a best practice issue.  One does it so
that each layer of the system handles only the properties
it needs.  Such layers include the organizations and humans
who process the information most effectively in a form and
using names most familiar in that domain.  That is why we
have XSLT etc.  Node is nodes, properties is properties. 
Names make the most difference to the mammals and they
will fight to the death for them.
Umm... human readability is useful.  It takes some practice,
but even when an IDE is more productive, occasionally you
have to open the file and poke and peek.  Note that even
with all of the Visual apps, you still need to edit code.  True
for C, Basic, Java etc and just as true for XML.


Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

-----Original Message-----
From: jwells123 [mailto:jwells123@email.msn.com]

Sorry if this is an old, dead horse on this list, but does anyone see any substance in the supposed "separation of content from presentation" feature of XML?
Since we had this years ago with databases and server-side scripts, I'm thinking this (and certain other misconceptions) are just attempts to create visual, easily demonstrable features for what is an inherently non-visual technology. Since XML no doubt owes some of its hype to its (distant) relation to HTML, which is visual, people wanted to be shown features of XML that they could "see."
In the same vein, has anyone else noticed lots of demonstrations of XML-using applications that make a point of exposing the XML itself, as if its readability were an asset to the end user? Since XML works in the background, it's hard to demonstrate its effects on the application from the user's point of view.
I'm thinking that being able to explain the root causes of these misconceptions will help me in explaining to people why they ARE misconceptions.