[
Lists Home |
Date Index |
Thread Index
]
Q: How do people learn markup?
A: 'View Source'.
This notion is one of the big guns that gets wheeled out in many
permathreads - 'binary XML', 'RDF, bad' perhaps even 'XML Schema, too
complicated'. To a lot of people it's the show stopper, the argument that
can never be defeated. Not being able to view source is the reason format X
died; being able to view source is the reason for format Y's success.
But I'm beginning to wonder if this argument really holds water any more.
Don't get me wrong, I'm sure it certainly used to be the case, that many
people here got their initial momentum into XML by looking at that there
text. I'm also sure that being able to view existing source can be a great
aid in learning a markup language. What I'm questioning is whether the
actual practice of 'View Source' really is so widespread these days, and
more importantly whether it offers such benefits for it to be a major factor
in language decisions. I'd be happy with the answer to : are people really
using 'View Source' that much? I hear it a lot, yet see little evidence.
One big source of doubt for me is what many markup languages look like these
days. Pick a few web pages at random, and 'View Source'. Chances are you'll
see a morass of different languages : HTML, Javascript, CSS. Does this
really offer significant benefit to a newcomer? On the more current sites
you'll see a load of <div>s and class='s. Do these really compare with the
<table> and <font> in terms of see and tell?
There are also the bits and pieces of XML that can be hard on the eye :
CDATA blocks, escaped characters, entities and good old namespaces. Ok, I
know there are people present that don't approve of XML namespaces, but if
anything their (alleged) inelegance is another case *against* 'View
Source'. Namespaces are there out in the wild.
There certainly are languages around that succumb nicely to
exposition-by-'View Source'. SVG is a good example - the elements have
human-friendly shape names, the structural grouping seems intuitively right
and the painter's model (layer on layer) fits well with our idea of document
order. But take a look at XSLT. How much does the source alone tell you
about what's going on? There are constructs that look familiar from
procedural languages, but how much will viewing source help a C programmer
grasp the idea of declarative programming?
Implicit in the 'View Source' argument is the assumption that somehow the
source will convey information on levels above and beyond the syntax. Sure,
if the element is called <table> there's a big clue about what it might
mean. But might not this be a dangerous assumption? It's easy enough to
misinterpret things, but if the hint looks explicit, then isn't any
erroneous interpretation going to be held that much stronger too? If a
furniture designer sees the element <table>, they're not likely to consider
the number of columns but whether it's pine or mahogany. Apart from
confusion between apparently human-friendly terms, there is also the often
opaque, arcane language that creeps in - what's this 'arcrole' business
then, guv?
Certainly people can learn different human languages based primarily with
the bits-on-the-wire of speech. No manual is needed. There are polyglot
illiterates. But there is more in the learning process than just a
plain-text stream. Other people act as validators, giving complex vocal
nuances and visual feedback. This isn't just on the syntax/grammar level
either. Bits-on-the-wire and/or syntax are necessary, but it's naive to
consider them sufficient.
Think I'm stretching a point here? Ok, move up the document to
xmlns="http://www.w3.org/1999/xhtml";. How many hits a day does that URL get
thanks to 'View Source'?
Turning the other way for a moment, in some XML discussions one might start
to believe that 'View Source' was a necessary precursor for persisting data.
Yet there's no 'View Source' on the contents of an RDBMS.
A side issue here is the possibility of another kind of misinterpretation.
If the XML syntax is a serialization of a different kind of model than is
being expected, then the misunderstanding can be systematic. I know RDF/XML
is considered an edge case around these parts, but confusion caused by
viewing it as 'just another XML syntax' is common. This is fundamentally the
same kind of confusion that people seeing XSLT as a procedural language
suffer from. Personally I suspect that we're going to see a lot more XML
used as a view of more complex model than simple hierarchical data (Coo-ee,
XQuery!)
One last point, I think we should be clear about what is and what isn't
'View Source'. If I need an XSLT stylesheet the first thing I'll do is open
an existing stylesheet and copy and paste half of it. Then I'll get
Michael's reference off the shelf. I bet a fair few folks here have the
bare-bones HTML 3.2 document etched into their lower cortex. But I'd argue
that nothing is actually gained from 'View Source' in this, all it is is
templating, the fact that it's a text format isn't of immediate relevance.
It isn't cut and dried, never is. That 'View Source' should be respected for
it's work in the past, and its utility in certain kinds of simple data
languages isn't really in doubt. I just don't think its tenure is beyond
question.
Cheers,
Danny.
----
http://dannyayers.com
PS. There's a little irony here - I sent this message last week to what I
thought was xml-dev, but was actually the OpenOffice XML list, somehow
listed in my contacts as Xml-dev. I cocked up - if only I'd viewed source!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xml.openoffice.org
For additional commands, e-mail: dev-help@xml.openoffice.org
|
