freelanceprogrammers.org Forum Index » XML / XSL
Rant: Is XML for documentation going the way of SGML? (long)
Joined: 21 Jan 2005
Posts: 1
Rant: Is XML for documentation going the way of SGML? (long)
i think you missed the real intention using sgml / xml as source format
for your technical documentation.
you try to divide content from its representation and thats just based
on standardized format.
i`ve seen lots of small companies using sgml. just using a "proprietary"
dtd, corresponding stysheets for well known editors and mature
publication processes to html / pdf / html-help ....
i think thats the benefit you got from sgml / xml -> write once /
publish everywhere ;-). getting a common data structure covers all
use-cases around is really impossible and not intent by sgml / xml
community. only concepts may be reusable. architectural frameworks like
DITA (http://www-106.ibm.com/developerworks/xml/library/x-dita1/) coming
from this direction. just a bunch of concepts, corresponding
implementation to start from.
your right, this approach always costs some money to implement, but much
less if you based on standards - inventing your own format to get
content representation costs much more effort or is nearby impossible.
alex
Larry Kollar wrote:
>This rant probably won`t be well-received here (or maybe I`m
>preaching to the choir), but I think it needs to be said -- and then
>discussed, if we are to avoid seeing XML sink into irrelevance as a
>documentation format. (As an *interchange* format, XML is well-
>established and in no danger of losing relevance, and that`s all I
>think needs to be said there. :-)
>
>The "SGML era" can be said to run from 1980 to early 1998 (when
>XML 1.0 was formalized). For most of that time, SGML was found
>primarily in the military supply and aerospace industries, with
>a few probes from academia and curious gearheads. Outside of
>heavy industry DTDs, I can think of only DocBook and TEI (and
>HTML, but I`ll hit that next) that have anything resembling
>widespread use today, and I`d wager that many people who are
>familiar with DocBook haven`t heard of TEI.
>
>The introduction of the HTML-driven World Wide Web in 1991/1992
>prompted many of us who were around at the time to check out
>HTML, and then SGML. Indeed, SGML probably got more attention
>in the first few years of the Web than it had throughout its
>previous history. And what did we find? A great idea -- a
>meta-language for markup -- surrounded by nearly impenetrable
>layers of what could be called support structure.
>
>Without incredibly complex DTDs (MIL-spec), strange formatting
>languages (FOSI, DSSSL), and databases, how would vendors justify
>six-figure deployment costs and five-figure yearly support
>contracts? SGML by itself was simply too simple to be a big
>money-maker. A university, or a documentation group in a small
>business, would have been able to use a DTD of middling complexity
>and a way to convert SGML to something like Script (IBM mainframes)
>or troff (Unix), or TeX. But margins for something like that
>weren`t big enough, then along came GUIs and word processors.
>
>It shouldn`t have been this way. SGML was designed to be an open
>standard, facilitating interchange between interested parties.
>Nothing proprietary about that, is there? Yet an SGML "solution"
>ended up costing orders of magnitude more than word processors
>using impenetrable binary formats. And outside those heavy
>industries that could afford the price tag, SGML became "Sounds
>Great, Maybe Later" and sank into obscurity.
>
>Then came HTML, truly the people`s DTD. For all the ragging HTML
>gets, it gave SGML a spotlight and got enough people interested
>in creating XML.
>
>Shortly after XML appeared came XSL, a highly complex transformation
>and formatting language that was quickly broken into XSLT and
>XSL-FO components. And we have XPath (another amoeba-like split
>of XSLT), XSchema, XQuery, SOAP, etc. More layers, many of which
>are fortunately geared toward the interchange side of things rather
>than documentation.
>
>So what`s the problem? In a word, attitude.
>
>The first problem is the attitude of "everything must be XML"
>once again leads us down the path of ignoring perfectly workable
>(and free, in most cases) technologies in favor of "solutions"
>that add expense and complexity and give little or no gain in
>return. Seriously, what does XSL-FO do that TeX or Groff can`t?
>I know for sure I can define a page layout in Groff using a lot
>fewer lines of code than I could in FO.
>
>The second problem is the attitude of many technical writers,
>who are simply sitting back and waiting for a shrink-wrapped
>XML "solution" instead of proactively building something that`s
>easy to implement and flexible enough to meet whatever our needs
>may be. If we wait for the vendors to give us *their* solution,
>we`ll be right back to the days of six-figure implementation
>and five-figure support costs -- and XML (as a documentation
>tool) will become "eXcellent, Maybe Later" and join SGML in
>obscurity.
>
>It doesn`t have to be that way. Not only is XML just as open
>(if not more so) than SGML, a plethora of Free, Open Source,
>and low-cost commercial tools have grown up around it or have
>been adapted to work with it. The pieces are lying all around
>us, like several model car kits all jumbled together. We need
>to start picking up pieces, fit them together, and start applying
>glue and paint.
>
>Needless to say, this is my personal opinion and not necessarily
>that of my employer.
>
>--
>Larry Kollar, Senior Technical Writer, ARRIS
>"Content creators are the engine that drives
>value in the information life cycle."
> -- Barry Schaeffer, on XML-Doc
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
Joined: 21 Jan 2005
Posts: 4
Rant: Is XML for documentation going the way of SGML? (long)
Hi Larry and all,
and thanks for this rant, I think you are expressing in words, a profound but
vague bad feeling I myself have had buried inside for years.
On Thursday 20 January 2005 21:26, Larry Kollar wrote:
> This rant probably won`t be well-received here (or maybe I`m
> preaching to the choir), but I think it needs to be said -- and then
> discussed, if we are to avoid seeing XML sink into irrelevance as a
> documentation format. (As an *interchange* format, XML is well-
> established and in no danger of losing relevance, and that`s all I
> think needs to be said there. :-)
[...]
> The second problem is the attitude of many technical writers,
> who are simply sitting back and waiting for a shrink-wrapped
> XML "solution" instead of proactively building something that`s
What is this "something" you have in mind?
> easy to implement and flexible enough to meet whatever our needs
> may be. If we wait for the vendors to give us *their* solution,
> we`ll be right back to the days of six-figure implementation
> and five-figure support costs -- and XML (as a documentation
> tool) will become "eXcellent, Maybe Later" and join SGML in
> obscurity.
>
> It doesn`t have to be that way. Not only is XML just as open
> (if not more so) than SGML, a plethora of Free, Open Source,
> and low-cost commercial tools have grown up around it or have
> been adapted to work with it. The pieces are lying all around
> us, like several model car kits all jumbled together. We need
> to start picking up pieces, fit them together, and start applying
> glue and paint.
We`ve been doing this in our own corner, although without the paint, and I
guess that`s what everyone is doing. Are you suggesting we join forces to
design the specifications (the "kit erecting instructions") of this
"something", and then build and paint it?
--
Camille Bégnis
NeoDoc Co-founder
http://neodoc.biz
Joined: 23 Jan 2005
Posts: 1
Rant: Is XML for documentation going the way of SGML? (long)
On Thu, 2005-01-20 at 15:26 -0500, Larry Kollar wrote:
> The second problem is the attitude of many technical writers,
> who are simply sitting back and waiting for a shrink-wrapped
> XML "solution" instead of proactively building something that`s
> easy to implement and flexible enough to meet whatever our needs
> may be. If we wait for the vendors to give us *their* solution,
> we`ll be right back to the days of six-figure implementation
> and five-figure support costs -- and XML (as a documentation
> tool) will become "eXcellent, Maybe Later" and join SGML in
> obscurity.
> It doesn`t have to be that way. Not only is XML just as open
> (if not more so) than SGML, a plethora of Free, Open Source,
> and low-cost commercial tools have grown up around it or have
> been adapted to work with it. The pieces are lying all around
> us, like several model car kits all jumbled together. We need
> to start picking up pieces, fit them together, and start applying
> glue and paint.
Sorry, I just couldn`t resist the urge to step in here with a plug for
Vex. This is *exactly* the kind of thing I`m trying to build: a free,
extensible, XML publishing platform. The main thing that I`m missing is
input from technical writers: which features are important, which can be
deferred, how can we improve usability, etc.
So maybe your call for tech writers to build tools should include a call
to lend their expertise to some enthusiastic open source developers.
jk
Joined: 13 Jun 2003
Posts: 14
Rant: Is XML for documentation going the way of SGML? (long)
Hello Larry.
In my case, you`re preaching to the choir.
There`s a divide between large scale documentation "shops" found in
government and document intensive industries like aircraft, and much
more numerous small groups typical of much of the software industry.
The former can afford to fly Hockos in for $15k a week to tell them
that documenation is an enterprise-wide issue that what ever 6-digit
product plus 5-digit annual fee she is promoting at the time can
solve, after the 5/6-digit figure is paid to have her favorite
consulting service come in and set everything up at no small
disruption to the company. This is the sort of "big thing" top
executives like to do to demonstrate that they`re not allowing their
company to fall behind the trend towards "intelligent, learning
enterprises."
On the other hand, there are thousands of small technical writing
operations, even peppered among the org charts of big companies, that
struggle to get by as a "cost of doing buiness." We all know what
that means - you`re an expense to be controlled and minimized.
In such an environment, the (false) allure of XML is "free tools"
and "independency from remote, uncaring vendors" like Adobe and
Microsoft appeals to managers, not to mention is another notch
of "professional relevancy" on our resumes - you never know when
you`ll be out on the pavement, only that the odds are there.
If XML for documenation is going the way of SGML, it is because all
the sound and furry of XML is failing to meet the vendor, paid
consultant and evangelist hype. For all the effort and struggle, few
are experiencing a break out into the promised land, just as was the
case with SGML.
The reason is simple. Pushing elements around doesn`t hold a candle
to WYSIWYG authoring or web publishing, and it just don`t pass a
beancounters muster; the economics aren`t there to justify the effort
on a cost-benefit basis nor are customers clammering and spending for
XML, what ever that is from a document user`s perspective.
Please, speak up if you`ve seen meaningful, benefits that resulted
from converting to XML. Things like the following would be impressive
coming from small-medium shops:
1. Sales of our products doubled when we converted.
2. Marketing told us we can add a 25% premium to the price of our
products for going XML.
3. We are so much more productive under XML that we laid off 30%
of our staff
4. Our doc department is now a profit center making money charging
for our XML documents and selling XML services to our customers.
5. Editors tell us our documentation is almost flawless now that
it`s in XML.
6. Customers have been measured 25% more productive because of our
XML documenation.
For most, the vision just isn`t there, and the utility economics -
sea changes in how effective documentation becomes or how much the
cost of producing of information drops - are simply lacking (except
in large, specialized situations). And, what is becoming increasinly
clear is the added cost and disruption of rolling in new technology,
tools and methods in a business that is already stretched thin and
cost conscious is a challenge with uncertain payoff.
I love technology, and SGML and XML were the holy grail in terms of
supporting a way of creating languages that talk about data and
documents and their contents in a way that software can work with, so
I`m having fun (that can be important to some managers). But, in all
honesty, the profession would be much better served by better project
management that more deeply understands the challenges of technical
documentation, including the economics of information, than one more
diversion in a history of diversions.
That`s not to say XML doesn`t hold promise; it does. The problem is
that the profession is a long way from understanding and envisioning
what that "promise" actually is and how it fits in other
possibilities. All we know for certain is that the effort and costs
keep mounting, those damn books never let up, and who knows if
they`ll be employed next month (better make sure that resume has all
the current buzz words present and accounted for).
As a certain fatigue sets in, it becomes it`s easier to let the
vendors sort it out. After all, no one was ever fired for buying
Adobe or Microsoft!
Where are the academics in all this - the thinking, envisioning wing
of the profession? With few exceptions, if they`re not discussing the
fine points of M.M. Bakhtin and his relevance to technical
documenation as an expression of post mondernist sensibilities,
they`re out doing field work collecting "document artifacts" and
organizing them into "genres" or fooling around with personal
websites (out) and blogs (in). The subject of "information and
technical writing economics" remains "getting a monthly paycheck."
And, true to form, XML appears in endless journal articles about "how
to make technical writing programs relevant by including it."
Not to scare anyone but it seems we`re on our own kids.
As always, nice touching base with you again Larry.
Tim
Joined: 28 Jan 2005
Posts: 2
Rant: Is XML for documentation going the way of SGML? (long)
Larry Kollar wrote:
> The second problem is the attitude of many technical writers,
> who are simply sitting back and waiting for a shrink-wrapped
> XML "solution" instead of proactively building something that`s
> easy to implement and flexible enough to meet whatever our needs
> may be. If we wait for the vendors to give us *their* solution,
> we`ll be right back to the days of six-figure implementation
> and five-figure support costs -- and XML (as a documentation
> tool) will become "eXcellent, Maybe Later" and join SGML in
> obscurity.
Like Tim said, I also got trapped in the GUI editor features list...
This was the core of your message IMHO Larry: waiting for XML editing to
be like Word. No wonder it got so much attention when MS introduced it`s
supposedly XML Word format (didn`t try it, won`t either). But the catch
22 is that writers don`t have the time (nor the skills, sometimes) to
write their own tools, so they rely on big corps like MS and Adobe to
provide those tools while they think of content (and then again,
"thinking" is an overstatement, sometimes). By the time an XML solution
pops up, it means restructuring the documentation department to adapt to
that wonderful, yet more complex solution.
> It doesn`t have to be that way. Not only is XML just as open
> (if not more so) than SGML, a plethora of Free, Open Source,
> and low-cost commercial tools have grown up around it or have
> been adapted to work with it. The pieces are lying all around
> us, like several model car kits all jumbled together. We need
> to start picking up pieces, fit them together, and start applying
> glue and paint.
Well... some of us are already doing that, picking up open source
software and enhancing them to drive documentation at XML speed. Tools
like Borges, VEX, OmegaT and emacs can *be* that XML solution. Then
again all those tools are mainly oriented towards the Linux* platforms:
in that environment, people are less afraid of the new and enigmatic,
unfriendly app. GUIs are not a must, but appreciated, at most.
I think it`s about open-mindedness (learning new ways to work) and
education (in school, even at university level, you`re not taught to use
a word processor, or even a text editor, you`re asked to use Word, plain
and simple).
Stop thinking dummy: write!
Thx for the rant opening Larry
K
Joined: 28 Jan 2005
Posts: 1
Rant: Is XML for documentation going the way of SGML? (long)
As a writer who has been in the trenches for some time with SGML and
XML, I`d like to second Larry`s excellent point that XML is in danger
of going the way of SGML.
In my experience, vendors work hard to hype buzzwords like "reuse" so
they can sell their tools, but are lax when it comes to explaining the
serious work that it still takes to use XML. I also agree that many
technical writers have an attitude problem: most of the seasoned doc
professionals I`ve worked with are militantly ignorant of anything
that would require changing old habits (like giving up shrink wrap).
Given the lack of traction among vendors and writers, I`m not
surprised that most software companies in my area (Boston) are still
FrameMaker/RoboHelp shops. As near as I can tell, XML has been adopted
mostly by the same kinds of organizations that embraced SGML: the
ones who can afford it. The last XML conference I attended was mainly
a venue for consultants to bring together high-end vendors and
information managers from large corporations. Far from being concerned
about the barriers to wider XML adoption, everybody there seemed
pleased to be exclusive stakeholders in a lucrative game. IMO, if this
is the dynamic that determines the direction of XML publishing, I
think it will be be another long, slow decline into oblivion - because
like SGML, it will lack a critical mass of vendors and users.
Surely what`s different this time around is a vigorous open source
community. If the people who are busy creating the core open source
systems and apps can keep them open and counterbalance the big funders
in driving standards, just maybe the proprietary vendors can be
dissuaded from killing the goose that lays the golden egg. If there`s
hope for the survival of XML publishing, it might be the growing
number of companies who are finding ways to accommodate the creative
engine that now underpins their entire market.
I`m not sure what to do about the attitude of technical writers. If
current job trends in that field are any indication, it may be an
academic question anyway.
Joined: 28 Jan 2005
Posts: 2
Rant: Is XML for documentation going the way of SGML? (long)
Our little firm began developing editorial applications based on SGML 15
years ago and have moved into XML as it became available. I think it can
be fairly said that the standards are not the problem. In fact, it is the
human part of the equation that vexes (and has always vexed) us. From
tech writing groups that fail to see the wisdom of capturing their
intellectual property in a notation (SGML/XML)that maximizes its value; to
IT groups that fail to see the differences between the orderly world,
bounded by relational technology, and the text world that breaks all of
those rules (and decides that the reason for this must be that text people
are just undisciplined); to top management that fails to include the value
of authors` time and information product value when it calculates the ROI
needed to fund text projects; to the software industry that for decades
ignored text forms in which most of the world`s information is kept, etc.,
etc. Perhaps all of this is to be expected. We are in the midst of a
massive cultural change in the way we inform ourselves. The last time we
went through this major a shift was when we gave up scrolls, available
only to the elite who were taught to read them, and reproduced books for
the masses whom we began also teaching to read. That took nearly 600
years, so perhaps we just need to persevere and understand that we may not
see, in our lifetime, the full fruition of what we are trying to do.
Regards,
Barry
http://www.xsystems.com/randomxml.htm"
-----------------------------------------------------------------
X.Systems, Inc. ...content solutions for the Internet Age
703-330-1645 www.xsystems.com
-----------------------------------------------------------------
superk <chris@...>
01/27/2005 09:48 PM
Please respond to
xml-doc@yahoogroups.com
To
xml-doc@yahoogroups.com
cc
Subject
Re: [xml-doc] Rant: Is XML for documentation going the way of SGML? (long)
Larry Kollar wrote:
> The second problem is the attitude of many technical writers,
> who are simply sitting back and waiting for a shrink-wrapped
> XML "solution" instead of proactively building something that`s
> easy to implement and flexible enough to meet whatever our needs
> may be. If we wait for the vendors to give us *their* solution,
> we`ll be right back to the days of six-figure implementation
> and five-figure support costs -- and XML (as a documentation
> tool) will become "eXcellent, Maybe Later" and join SGML in
> obscurity.
Like Tim said, I also got trapped in the GUI editor features list...
This was the core of your message IMHO Larry: waiting for XML editing to
be like Word. No wonder it got so much attention when MS introduced it`s
supposedly XML Word format (didn`t try it, won`t either). But the catch
22 is that writers don`t have the time (nor the skills, sometimes) to
write their own tools, so they rely on big corps like MS and Adobe to
provide those tools while they think of content (and then again,
"thinking" is an overstatement, sometimes). By the time an XML solution
pops up, it means restructuring the documentation department to adapt to
that wonderful, yet more complex solution.
> It doesn`t have to be that way. Not only is XML just as open
> (if not more so) than SGML, a plethora of Free, Open Source,
> and low-cost commercial tools have grown up around it or have
> been adapted to work with it. The pieces are lying all around
> us, like several model car kits all jumbled together. We need
> to start picking up pieces, fit them together, and start applying
> glue and paint.
Well... some of us are already doing that, picking up open source
software and enhancing them to drive documentation at XML speed. Tools
like Borges, VEX, OmegaT and emacs can *be* that XML solution. Then
again all those tools are mainly oriented towards the Linux* platforms:
in that environment, people are less afraid of the new and enigmatic,
unfriendly app. GUIs are not a must, but appreciated, at most.
I think it`s about open-mindedness (learning new ways to work) and
education (in school, even at university level, you`re not taught to use
a word processor, or even a text editor, you`re asked to use Word, plain
and simple).
Stop thinking dummy: write!
Thx for the rant opening Larry
K
Yahoo! Groups Links
[Non-text portions of this message have been removed]
Joined: 28 Jan 2005
Posts: 2
Rant: Is XML for documentation going the way of SGML? (long)
Our little firm began developing editorial applications based on SGML
15 years ago and have moved into XML as it became available. I think
it can be fairly said that the standards are not the problem. In
fact, it is the human part of the equation that vexes (and has always
vexed) us. From tech writing groups that fail to see the wisdom of
capturing their intellectual property in a notation (SGML/XML)that
maximizes its value; to IT groups that fail to see the differences
between the orderly world, bounded by relational technology, and the
text world that breaks all of those rules (and decides that the
reason for this must be that text people are just undisciplined); to
top management that fails to include the value of authors` time and
information product value when it calculates the ROI needed to fund
text projects; to the software industry that for decades ignored text
forms in which most of the world`s information is kept, etc., etc.
Perhaps all of this is to be expected. We are in the midst of a
massive cultural change in the way we inform ourselves. The last
time we went through this major a shift was when we gave up scrolls,
available only to the elite who were taught to read them, and
reproduced books for the masses whom we began also teaching to read.
That took nearly 600 years, so perhaps we just need to persevere and
understand that we may not see, in our lifetime, the full fruition of
what we are trying to do.
Regards,
Barry
Joined: 13 Jun 2003
Posts: 14
Rant: Is XML for documentation going the way of SGML? (long)
Peter Ring and Denis Bradford both noted that the open source
community surrounding XML is what is different than SGML (let`s
include the Frame document object model too). I was around in the
1980s and there was a community then who also responded to the
potential of markup languages although there wasn`t the open
landscape that the web afforded XML.
SGML became "captured" by big, deep pocket interests - Barry noticed
signs of this happening at XML conventions. An open community is no
guarentee of that not happening with XML if it fails to result in
solutions that directly address the primary charter of technical
documentation shops - quick, on demand, spot on information through
good writing and appropriate technology at stable to reduced cost.
XML/SGML is relevant only as far as it helps fulfill the entire
charter.
Currently, except for a few large scale, specialized situations, there
is scant evidence that it does, especially in small shop settings that
characterize more technical writing organizations.
On reason is that technological change rarely succeeds without
organizational changes, and the sophistication of most technial
writing managers is inadequate even for current methods. Inventory
mangement, for example, is crude and light years away from the
management of topics.
The same is true of the prevailing view of "meta data" as paragraphs
and inline markers for "code" and a few types based on purpose
(reference, instructions, concept). No where to be seen is thinking
about language that describes the content of a product. For example,
how do I say the following in DocBook?
SOFTWARE > API > DATABASE > CONNECTION
Wouldn`t I want to say something like that to map out content as a
basis for improving access and ensuring complete content coverage?
Peter talked about refactoring the content and the workflow, and he
rightly noted that this does does not depend on structured markup per
se. However, he stumbled when he claimed that your chanced of getting
trapped with XML is less than with proprietary storage formats. But
how can he say that! FrameMaker has reliably supported their model
for nearly 20 years now with millions of documents to attest to its
stability whereas XML is relatively new and has produced no where
near the body of documents (and, I`ll note, a good part of these are
in the FrameMaker proprietary storage format). It`s premature to make
such claims especially with next to no proof.
Yes, that`s right! Regardless of XML being the latest rage in academic
technical writing departments, NO ONE is doing credible research on
these issues. That leaves the field open to vendors with vested
interest in promoting XML. That`s not to say that their claims aren`t
right within specific situations; we just can`t tell how encompassing
these claims can be and remain valid.
Barry and Dennis both commented on writers and the profession. Barry
suggested that jobs are under pressure and may be more threatened
than XML. This suggests the motivation of many writers to chase
technology without fully appreciating it simply to stay ahead of the
relevance curve. The irony of this is there are scenarios where less
staff is needed, replaced with greater efficiency and lower cost,
"egoless" topic writers. XML advocates may be increasing pressure on
their jobs and profession. The response of the rank and file is
predictable - torn between getting XML on their resume and a
reluctance to fully embrace change that could result in the loss of
their job.
Barry suggested that "text people are just undisciplined," and
that seems to characterize the profession. Taking links for example.
Goto "software links" was one of the seminal debates in software
engineering and it concluded that they are bad but 30 years later
there`s been no similar examination of links in technical writing.
What are the academics and leaders of the profession doing?
Certainly, a better editor isn`t going to resolve these and other
critical issues in the challenge of XML. At some point, they need
to be addressed head on if the potential of XML and what it represents
is to be realized.
Tim
Joined: 13 Jun 2003
Posts: 39
Rant: Is XML for documentation going the way of SGML? (long)
I`ve been chewing on the responses, not finding much new to contribute
to the discussion, but I wanted to throw in two cents to something Tim
said:
> The same is true of the prevailing view of "meta data" as paragraphs
> and inline markers for "code" and a few types based on purpose
> (reference, instructions, concept). No where to be seen is thinking
> about language that describes the content of a product. For example,
> how do I say the following in DocBook?
>
> SOFTWARE > API > DATABASE > CONNECTION
>
> Wouldn`t I want to say something like that to map out content as a
> basis for improving access and ensuring complete content coverage?
Would the "role" attribute be suitable here?
Tim, chime in here if I get off-track, but I think you want to make
explicit things that have been implicit since the beginning of
technical documentation. In a printed manual, your example would
have likely appeared in a "XYZ Software Application Programmer`s
Reference" manual, under a chapter titled "Database Access Functions."
The very location of the topic in question, the book and chapter that
it appears in, is the metadata that describes its content. This
shared context between writer and reader is an assumption that`s so
well-internalized that I`ve never really thought of it consciously
until you brought it up. Ken said earlier, "writers don`t always
(ever?) think hierarchically," but we do. We just don`t realize it.
Moving away from books into a web of linked topics, the implied meta-
data becomes more tenuous. Without the shared context of topics
organized into book, chapter, and section, the reader can become
deprived of shared context although the writer may still organize
topics into a hierarchical structure like XYZ/API/Database and not
realize that the reader no longer has access to the structure.
Computers, which have trouble with implied anything to begin with,
end up completely at sea. (You can see this any time you do a Google
search using keywords that have more than one meaning.)
There *have* been forays into resolving the problem, trying to turn
the implicit into the explicit -- breadcrumb trails, for example.
http://www.webdesignpractices.com/navigation/breadcrumb.html was
near the top of a Google for "web bread crumb" and describes the
concept pretty well. So the example topic might have a string like
"XYZ | Software API | Database" at the top & bottom of the page,
with links to hop back to the appropriate heading page.
Another common navigation aid is the multi-pane/frame "help" style,
displaying an outline of the documentation, usually highlighting
the topic on the screen in some way. Some readers at least may find
this type of aid more comfortable, because it restores that implied
metadata -- the entire family tree, and the topic`s place in that
family, is quickly recognized. OmniHelp is an open-source version
of this concept; see http://www.omsys.com/dcl/omnihelp.htm for
details.
So there *is* some research being done, mainly ad hoc, different
people trying different things. I think some of Chomsky`s work may
have touched on what I`m calling "shared context"; I just wish his
work was a bit more approachable.
So we`re trying to deal with that groove/rut we`ve created, as
Barry said, over the last 600 years or so. We organize topics into
a hierarchy, often sub-consciously, and it`s only been in the last
30 years or so (since SGML first appeared) that we`ve made any
attempt to formally codify how we do what we already know how to
do. This line of thinking leads to another fine rant:
How much formal structure do we really need?
One thing I griped about in my original rant was the complexity
of many of the popular DTDs. I described HTML as "a people`s
DTD," and it is -- you can fit a quick reference to HTML`s
structure and the most common tags on a single sheet of paper
without making the type very small at all. Anyone with a little
motivation can memorize enough HTML syntax to be conversant in
a few hours. Many people disparage HTML as *too* simple -- but
is it really?
In the shared context of a printed manual, a reader sees italic
text and can quickly determine whether it`s a term, the name of
another manual, or something the writer deemed important enough
to call attention to. Even simple old HTML4 can explicitly
distinguish between them using dfn, cite, and em, respectively.
If we`re writing for humans, and I think primarily we still are,
we could just use the <i>i tag</i> for all three and know they
will sort it out without even thinking about it. If we restore
the shared context, whether through a multi-pane help system,
breadcrumbs, or some other method, readers will be happy.
If we`re writing primarily for humans, but want computers to
catch on, we have to be a little more explicit. For example, if
we`re using breadcrumbs to provide shared context, we could
wrap the string in a "breadcrumb" tag or whatever we want to
call it, just to tell processing scripts what to look for. HTML
has a META tag that could be used to provide similar information
behind the scenes (i.e. not visible to the reader without using
"View Source"). Example:
[meta name="context" content="XYZ|API|Database" /]
If needed, the div and span tags, in conjunction with the
"class" attribute, could also be used to provide metadata at the
intra-page level.
Writers already know how to write, and resent authoring tools
that get in the way of writing (witness the gripes up-thread
about XML editors that don`t allow structure violations). If
we keep in mind the implied context that our human readers
expect, while providing sufficient metadata for the computer
readers, then plain HTML (maybe with some minimal extensions)
might be all we *really* need. Bang out topics in whatever
tool you like, use HTML Tidy to turn it into valid XHTML, add
metadata, and go.
Complexity has gotten us nowhere. Let`s try simplicity.
--
Larry Kollar, Senior Technical Writer, ARRIS
"Content creators are the engine that drives
value in the information life cycle."
-- Barry Schaeffer, on XML-Doc
"Ambot Sakoy" <binisiya@...> wrote on 01/28/2005 12:22:43 PM:
>
>
> Peter Ring and Denis Bradford both noted that the open source
> community surrounding XML is what is different than SGML (let`s
> include the Frame document object model too). I was around in the
> 1980s and there was a community then who also responded to the
> potential of markup languages although there wasn`t the open
> landscape that the web afforded XML.
>
> SGML became "captured" by big, deep pocket interests - Barry noticed
> signs of this happening at XML conventions. An open community is no
> guarentee of that not happening with XML if it fails to result in
> solutions that directly address the primary charter of technical
> documentation shops - quick, on demand, spot on information through
> good writing and appropriate technology at stable to reduced cost.
>
> XML/SGML is relevant only as far as it helps fulfill the entire
> charter.
> Currently, except for a few large scale, specialized situations, there
> is scant evidence that it does, especially in small shop settings that
> characterize more technical writing organizations.
>
> On reason is that technological change rarely succeeds without
> organizational changes, and the sophistication of most technial
> writing managers is inadequate even for current methods. Inventory
> mangement, for example, is crude and light years away from the
> management of topics.
>
> The same is true of the prevailing view of "meta data" as paragraphs
> and inline markers for "code" and a few types based on purpose
> (reference, instructions, concept). No where to be seen is thinking
> about language that describes the content of a product. For example,
> how do I say the following in DocBook?
>
> SOFTWARE > API > DATABASE > CONNECTION
>
> Wouldn`t I want to say something like that to map out content as a
> basis for improving access and ensuring complete content coverage?
>
> Peter talked about refactoring the content and the workflow, and he
> rightly noted that this does does not depend on structured markup per
> se. However, he stumbled when he claimed that your chanced of getting
> trapped with XML is less than with proprietary storage formats. But
> how can he say that! FrameMaker has reliably supported their model
> for nearly 20 years now with millions of documents to attest to its
> stability whereas XML is relatively new and has produced no where
> near the body of documents (and, I`ll note, a good part of these are
> in the FrameMaker proprietary storage format). It`s premature to make
> such claims especially with next to no proof.
>
> Yes, that`s right! Regardless of XML being the latest rage in academic
> technical writing departments, NO ONE is doing credible research on
> these issues. That leaves the field open to vendors with vested
> interest in promoting XML. That`s not to say that their claims aren`t
> right within specific situations; we just can`t tell how encompassing
> these claims can be and remain valid.
>
> Barry and Dennis both commented on writers and the profession. Barry
> suggested that jobs are under pressure and may be more threatened
> than XML. This suggests the motivation of many writers to chase
> technology without fully appreciating it simply to stay ahead of the
> relevance curve. The irony of this is there are scenarios where less
> staff is needed, replaced with greater efficiency and lower cost,
> "egoless" topic writers. XML advocates may be increasing pressure on
> their jobs and profession. The response of the rank and file is
> predictable - torn between getting XML on their resume and a
> reluctance to fully embrace change that could result in the loss of
> their job.
>
> Barry suggested that "text people are just undisciplined," and
> that seems to characterize the profession. Taking links for example.
> Goto "software links" was one of the seminal debates in software
> engineering and it concluded that they are bad but 30 years later
> there`s been no similar examination of links in technical writing.
> What are the academics and leaders of the profession doing?
>
> Certainly, a better editor isn`t going to resolve these and other
> critical issues in the challenge of XML. At some point, they need
> to be addressed head on if the potential of XML and what it represents
> is to be realized.
>
> Tim
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
Joined: 02 Feb 2005
Posts: 3
Rant: Is XML for documentation going the way of SGML? (long)
A slight expansion of your comment on search context, Larry:
The Vivisimo search engine is an interesting antidote to the "flat"
Google search:
http://www.vivismo.com
The FAQ has some background on the benefits of clustered searches:
http://vivisimo.com/html/faq
Sheila
--- In xml-doc@yahoogroups.com, Larry Kollar <larry.kollar@a...> wrote:
> Moving away from books into a web of linked topics, the implied meta-
> data becomes more tenuous. Without the shared context of topics
> organized into ... (You can see this any time you do a Google
> search using keywords that have more than one meaning.)
Joined: 02 Feb 2005
Posts: 2
Rant: Is XML for documentation going the way of SGML? (long)
Well, having watched this one go round the houses, I finally decided to dive
in and deposit $0.02. I advocate designing semantically rich schemas. Going
for documentation-specific schemas adds IMHO little value to the information
and serves only to annoy authors who are saddled with all the extra nonsense
of markup languages compared to a rich DTP environment. At least with
semantically rich schemas, the potential long term value-add and flexibility
offer huge benefits over a traditional system.
I was responsible for designing an SGML-based publishing system in the late
90s for a very large, complex set of technical documentation and training
materials. We bought Astoria for the content management part, used
FrameMaker+SGML for the authoring part and designed all our own schemas
(SGML DTDs) to describe the content we were capturing in the content
management system. The schemas all described bite-sized, atomic units of
information that could be used in any valid context.
We examined DocBook and quickly dismissed it as it didn`t describe our
content in any useful way. We already had an extremely sophisticated set of
FrameMaker templates that achieved everything we could have achieved through
DocBook, so reengineering it all over again in SGML and Omnimark seemed like
an enormous waste of time and money. Instead, tasked with the goal of never
publishing a broken link and being able to infinitely repurpose all our
content across any delivery platform both now and in any future (as yet
undesigned) document structure, we performed an information mapping exercise
that resulted in 50+ DTDs which we could knit together via a HyTime-based
Link Manager system which Chrystal Software kindly built for us to spec. The
end result comprised 65 DTDs, when you count the various publication DTDs
that we built for things like Trainers` Manuals to accompany course
material, Installation Guides, and so on.
The online published results were great -- navigation bars showed where
you`d been, menu bars showed the context you found yourself in, and
therefore where you could also go, See Also links enriched every page, all
terms had a glossary and a concept topic to back them up, every syntactical
explanation linked to an example, etc. etc. It was a constantly moving
kaleidoscope of richly interlinked information, similar in concept to the
promise of topic maps and the semantic web. Users generally loved it. The
people who had the biggest problem with it were the authors, who hated using
the software to get the stuff written. (Course developers even went on
strike and insisted on reverting to handing in copy in regular FrameMaker,
for a publishing assistant to transcribe in SGML.) Technology back then
really wasn`t up to the task, either on the hardware or the software front.
As an architect, I conclude this:
- For design flexibility, it was fantastic.
- For maintainability, it was awful.
- The technology has moved on apace, however, and I think that it would now
be a much easier project all round.
- If you design your own schemas, you don`t have any discussion groups or
industry specialists to go to for advice and tips.
For those who are interested, you can read all about this at
http://www.idealliance.org/papers/dx_xmle04/papers/03-02-04/03-02-04.pdf.
Tasked with moving to XML now, I would definitely choose semantically rich
schemas over documentation-specific schemas any day of the week. The pro`s
far outweigh the con`s.
Forgive me please if I appear to be treading on anybody`s toes here.
Jim Gabriel
> -----Original Message-----
> From: Larry Kollar [mailto:larry.kollar@...]
> Sent: 01 February 2005 17:13
> To: xml-doc@yahoogroups.com
> Subject: Re: [xml-doc] Re: Rant: Is XML for documentation
> going the way of SGML? (long)
>
>
> I`ve been chewing on the responses, not finding much new to contribute
> to the discussion, but I wanted to throw in two cents to something Tim
> said:
>
> > The same is true of the prevailing view of "meta data" as paragraphs
> > and inline markers for "code" and a few types based on purpose
> > (reference, instructions, concept). No where to be seen is thinking
> > about language that describes the content of a product. For example,
> > how do I say the following in DocBook?
> >
> > SOFTWARE > API > DATABASE > CONNECTION
> >
> > Wouldn`t I want to say something like that to map out content as a
> > basis for improving access and ensuring complete content coverage?
>
> Would the "role" attribute be suitable here?
>
> Tim, chime in here if I get off-track, but I think you want to make
> explicit things that have been implicit since the beginning of
> technical documentation. In a printed manual, your example would
> have likely appeared in a "XYZ Software Application Programmer`s
> Reference" manual, under a chapter titled "Database Access Functions."
> The very location of the topic in question, the book and chapter that
> it appears in, is the metadata that describes its content. This
> shared context between writer and reader is an assumption that`s so
> well-internalized that I`ve never really thought of it consciously
> until you brought it up. Ken said earlier, "writers don`t always
> (ever?) think hierarchically," but we do. We just don`t realize it.
>
> Moving away from books into a web of linked topics, the implied meta-
> data becomes more tenuous. Without the shared context of topics
> organized into book, chapter, and section, the reader can become
> deprived of shared context although the writer may still organize
> topics into a hierarchical structure like XYZ/API/Database and not
> realize that the reader no longer has access to the structure.
> Computers, which have trouble with implied anything to begin with,
> end up completely at sea. (You can see this any time you do a Google
> search using keywords that have more than one meaning.)
>
>
> There *have* been forays into resolving the problem, trying to turn
> the implicit into the explicit -- breadcrumb trails, for example.
> http://www.webdesignpractices.com/navigation/breadcrumb.html was
> near the top of a Google for "web bread crumb" and describes the
> concept pretty well. So the example topic might have a string like
> "XYZ | Software API | Database" at the top & bottom of the page,
> with links to hop back to the appropriate heading page.
>
> Another common navigation aid is the multi-pane/frame "help" style,
> displaying an outline of the documentation, usually highlighting
> the topic on the screen in some way. Some readers at least may find
> this type of aid more comfortable, because it restores that implied
> metadata -- the entire family tree, and the topic`s place in that
> family, is quickly recognized. OmniHelp is an open-source version
> of this concept; see http://www.omsys.com/dcl/omnihelp.htm for
> details.
>
> So there *is* some research being done, mainly ad hoc, different
> people trying different things. I think some of Chomsky`s work may
> have touched on what I`m calling "shared context"; I just wish his
> work was a bit more approachable.
>
>
> So we`re trying to deal with that groove/rut we`ve created, as
> Barry said, over the last 600 years or so. We organize topics into
> a hierarchy, often sub-consciously, and it`s only been in the last
> 30 years or so (since SGML first appeared) that we`ve made any
> attempt to formally codify how we do what we already know how to
> do. This line of thinking leads to another fine rant:
>
> How much formal structure do we really need?
>
> One thing I griped about in my original rant was the complexity
> of many of the popular DTDs. I described HTML as "a people`s
> DTD," and it is -- you can fit a quick reference to HTML`s
> structure and the most common tags on a single sheet of paper
> without making the type very small at all. Anyone with a little
> motivation can memorize enough HTML syntax to be conversant in
> a few hours. Many people disparage HTML as *too* simple -- but
> is it really?
>
> In the shared context of a printed manual, a reader sees italic
> text and can quickly determine whether it`s a term, the name of
> another manual, or something the writer deemed important enough
> to call attention to. Even simple old HTML4 can explicitly
> distinguish between them using dfn, cite, and em, respectively.
> If we`re writing for humans, and I think primarily we still are,
> we could just use the <i>i tag</i> for all three and know they
> will sort it out without even thinking about it. If we restore
> the shared context, whether through a multi-pane help system,
> breadcrumbs, or some other method, readers will be happy.
>
> If we`re writing primarily for humans, but want computers to
> catch on, we have to be a little more explicit. For example, if
> we`re using breadcrumbs to provide shared context, we could
> wrap the string in a "breadcrumb" tag or whatever we want to
> call it, just to tell processing scripts what to look for. HTML
> has a META tag that could be used to provide similar information
> behind the scenes (i.e. not visible to the reader without using
> "View Source"). Example:
>
> [meta name="context" content="XYZ|API|Database" /]
>
> If needed, the div and span tags, in conjunction with the
> "class" attribute, could also be used to provide metadata at the
> intra-page level.
>
> Writers already know how to write, and resent authoring tools
> that get in the way of writing (witness the gripes up-thread
> about XML editors that don`t allow structure violations). If
> we keep in mind the implied context that our human readers
> expect, while providing sufficient metadata for the computer
> readers, then plain HTML (maybe with some minimal extensions)
> might be all we *really* need. Bang out topics in whatever
> tool you like, use HTML Tidy to turn it into valid XHTML, add
> metadata, and go.
>
> Complexity has gotten us nowhere. Let`s try simplicity.
>
> --
> Larry Kollar, Senior Technical Writer, ARRIS
> "Content creators are the engine that drives
> value in the information life cycle."
> -- Barry Schaeffer, on XML-Doc
>
> "Ambot Sakoy" <binisiya@...> wrote on 01/28/2005 12:22:43 PM:
>
> >
> >
> > Peter Ring and Denis Bradford both noted that the open source
> > community surrounding XML is what is different than SGML (let`s
> > include the Frame document object model too). I was around in the
> > 1980s and there was a community then who also responded to the
> > potential of markup languages although there wasn`t the open
> > landscape that the web afforded XML.
> >
> > SGML became "captured" by big, deep pocket interests - Barry noticed
> > signs of this happening at XML conventions. An open community is no
> > guarentee of that not happening with XML if it fails to result in
> > solutions that directly address the primary charter of technical
> > documentation shops - quick, on demand, spot on information through
> > good writing and appropriate technology at stable to reduced cost.
> >
> > XML/SGML is relevant only as far as it helps fulfill the entire
> > charter.
> > Currently, except for a few large scale, specialized
> situations, there
> > is scant evidence that it does, especially in small shop
> settings that
> > characterize more technical writing organizations.
> >
> > On reason is that technological change rarely succeeds without
> > organizational changes, and the sophistication of most technial
> > writing managers is inadequate even for current methods. Inventory
> > mangement, for example, is crude and light years away from the
> > management of topics.
> >
> > The same is true of the prevailing view of "meta data" as paragraphs
> > and inline markers for "code" and a few types based on purpose
> > (reference, instructions, concept). No where to be seen is thinking
> > about language that describes the content of a product. For example,
> > how do I say the following in DocBook?
> >
> > SOFTWARE > API > DATABASE > CONNECTION
> >
> > Wouldn`t I want to say something like that to map out content as a
> > basis for improving access and ensuring complete content coverage?
> >
> > Peter talked about refactoring the content and the workflow, and he
> > rightly noted that this does does not depend on structured
> markup per
> > se. However, he stumbled when he claimed that your chanced
> of getting
> > trapped with XML is less than with proprietary storage formats. But
> > how can he say that! FrameMaker has reliably supported their model
> > for nearly 20 years now with millions of documents to attest to its
> > stability whereas XML is relatively new and has produced no where
> > near the body of documents (and, I`ll note, a good part of these are
> > in the FrameMaker proprietary storage format). It`s
> premature to make
> > such claims especially with next to no proof.
> >
> > Yes, that`s right! Regardless of XML being the latest rage
> in academic
> > technical writing departments, NO ONE is doing credible research on
> > these issues. That leaves the field open to vendors with vested
> > interest in promoting XML. That`s not to say that their
> claims aren`t
> > right within specific situations; we just can`t tell how
> encompassing
> > these claims can be and remain valid.
> >
> > Barry and Dennis both commented on writers and the profession. Barry
> > suggested that jobs are under pressure and may be more threatened
> > than XML. This suggests the motivation of many writers to chase
> > technology without fully appreciating it simply to stay ahead of the
> > relevance curve. The irony of this is there are scenarios where less
> > staff is needed, replaced with greater efficiency and lower cost,
> > "egoless" topic writers. XML advocates may be increasing pressure on
> > their jobs and profession. The response of the rank and file is
> > predictable - torn between getting XML on their resume and a
> > reluctance to fully embrace change that could result in the loss of
> > their job.
> >
> > Barry suggested that "text people are just undisciplined," and
> > that seems to characterize the profession. Taking links for example.
> > Goto "software links" was one of the seminal debates in software
> > engineering and it concluded that they are bad but 30 years later
> > there`s been no similar examination of links in technical writing.
> > What are the academics and leaders of the profession doing?
> >
> > Certainly, a better editor isn`t going to resolve these and other
> > critical issues in the challenge of XML. At some point, they need
> > to be addressed head on if the potential of XML and what it
> represents
> > is to be realized.
> >
> > Tim
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
Joined: 13 Jun 2003
Posts: 14
Rant: Is XML for documentation going the way of SGML? (long)
Larry,
I think you have inadvertantly concluded that one the things that XML
is "good" for is making technical writers think and talk explicitly
about structures, including hierarchy, they intuitively already work
with. This includes not only the obvious structures that make up
documents but the "structuring" of information to these conventions.
But, if we look at leading efforts, like DocBook, we can see that
writers haven`t gotten very far. They continue to confuse meta-data -
data about data - with the "container" in which information is kept.
It is simply an instance of the general document model of Frame or
other established tools rendered in XML for a set of specialized
documents (software).
This gives us a langauge we can share as writers when talking about
containers but where is the common language for talking about content?
As you might say, "it`s in the text, the title, the chapter heading"
but remember, we`re talking about a "programatic conversation," and to
a program, such text doesn`t mean much without a reference to identify
it against.
We are far from dealing with dynamic issues; migration of legacy
material, change and maintenance over time.
In the end, you call for "simplicity," and that can certainly include
"plain old books" in many circumstances. But, what we are struggling
with here is the promise of a technology that can improve the use and
access (fast, "right" information, on demand) of information, and even
offer the means for quantatively testing certain quality dimensions of
documentation; a trade-off of complexity for better leveraged information.
Such a trade-off implies a significant committment of resources and a
test as to whether or not the benefits are worth the cost. In many
situations, the calculation will prove that "plain old documents"
cannot be beat.
Even if that turns out to be the case, you might be right in that the
lessons of XML can reinforce the "good practices" you mentioned
writers already practice and even inspire better application of them;
concise, well cataloged libraries, with documents with good, clear,
consistent structure, formed appropriately to thoughtfully contain the
information, with various indexes to give quick, smart access to key
pieces of information.
It so happens that this is the very prerequsite that seems necessary
for a relatively easy, non-disruptive, low-cost, successful migration
to DocBook-like XML and structure. If you meet this prerequsite, then
you are left with the question "is it worth paying to do in XML what
you`re already doing for "free" (relatively speaking)?"
> Complexity has gotten us nowhere. Let`s try simplicity.
Or something more fundamental like "at what point are the imagined
benefits worth the effort and complexity, and just how will we know?"
Tim
Joined: 02 Feb 2005
Posts: 1
Rant: Is XML for documentation going the way of SGML? (long)
Jim;
A great example of Gabriel tooting his own horn: I like it!
Your post (and this is my two cents worth) and others like it moves this
whole discussion closer to the main issue: there is currently a large imbalance
in current XML practice between the structure of content (the containers) and
the content itself. The problem is particularly evident where you see a
large, disciplined effort dedicated to managing the form of the content while
relegating the meaning and relevance of the content itself (which is where I
thought XML was supposed to be going) to the less rigorous domains of metadata
and conditional processing.
Designing and building an information architecture that intentionally
focuses on semantic elements restores the balance, and in my view makes all
kinds
of sense when the conversation turns to things like reusing and repurposing
content. It makes much more sense to speak about reuse in a semantic sense than
a structural one. That is not to say that structure is not critical - it
just can`t be the only thing.
Apologies if this appears a little disjointed I am a little rushed this
morning. In the final analysis, especially when considering things like
internationalization of products and services, creating a better balance between
the
holy trinity of user-centered information: context, container, and content
might head off the slide of xml into the void.
Regards.
John O`
[Non-text portions of this message have been removed]
Joined: 02 Feb 2005
Posts: 1
Rant: Is XML for documentation going the way of SGML? (long)
Testing...
I`ve posted twice, neither of them seem to have made it to the list...
Sorry for the bother,
-Jason
-----Original Message-----
From: ogormanjjka@... [mailto:ogormanjjka@...]
Sent: Wednesday, February 02, 2005 9:06 AM
To: xml-doc@yahoogroups.com
Subject: Re: [xml-doc] Re: Rant: Is XML for documentation going the way
of SGML? (long)
Jim;
A great example of Gabriel tooting his own horn: I like it!
Your post (and this is my two cents worth) and others like it moves this
whole discussion closer to the main issue: there is currently a large
imbalance
in current XML practice between the structure of content (the containers)
and
the content itself. The problem is particularly evident where you see a
large, disciplined effort dedicated to managing the form of the content
while
relegating the meaning and relevance of the content itself (which is where I
thought XML was supposed to be going) to the less rigorous domains of
metadata
and conditional processing.
Designing and building an information architecture that intentionally
focuses on semantic elements restores the balance, and in my view makes all
kinds
of sense when the conversation turns to things like reusing and repurposing
content. It makes much more sense to speak about reuse in a semantic sense
than
a structural one. That is not to say that structure is not critical - it
just can`t be the only thing.
Apologies if this appears a little disjointed I am a little rushed this
morning. In the final analysis, especially when considering things like
internationalization of products and services, creating a better balance
between the
holy trinity of user-centered information: context, container, and content
might head off the slide of xml into the void.
Regards.
John O`
[Non-text portions of this message have been removed]
Yahoo! Groups Links
All times are GMT
Page 1 of 2
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Freelace Website Designer - Customer web design and software building.
China Wholesale - Electronics Products
Character Studio - Tutorials and Help
China Wholesale - Electronics Products
Character Studio - Tutorials and Help