[
Lists Home |
Date Index |
Thread Index
]
From: Nathan Young -X (natyoung - Artizen at Cisco)
[mailto:natyoung@cisco.com]
>> On the other hand, there are existence proofs
>> for using HTML for high end publishing.
>If you use XHTML for publishing a book you may not get a reduction in
>complexity.
True. What you get is a reduction of surface area: the number of
items, terms or parts needed to manage some repeatable process. IOW,
if XHTML + CSS + SVG do the job well enough, I don't have to invest
in a word processing system for an alternative format. (NOTE: per
job. I might have to for other jobs or for jobs other people do.)
>Textbooks have enough complexity and structure and are
>different enough from web pages that shoehorning them into XHTML has
>costs of its own.
Yes. It depends on the job, who does the job, how often they do it,
etc. In a software subscription model, one wants to keep costs low
by not having apps one doesn't use laying about. If one does need
them, then immediate learning curve is an issue, so one looks to
the repeatability of the task. In publishing, it is possible the
author only needs a simple wp system and an editor and layout artist
do the other tasks. If I am a technical reviewer, I want the content
but don't always need a well-formattted version; in fact, I want the
version I can annotate easily. So now, if I use the XHTML version,
I need annotation features or I use a pen.
>The tighter a document format is focused on a specific use, the simpler
>it can be. Part of the reason that word processing formats are so
>complex is that word processors are used for all kinds of things that
>aren't word processing.
Yes, or jobs that have different tool requirements. The question
becomes do I want a swiss army knife or a virtual swiss army knife
(blades added on request). Is there a cost break for that? If
not, then I have to buy the swiss army knife.
>> From where I sit, Bray's namespaced thought experiment
>> makes sense. Always has. Structural editors make
>> sense. Always have (been doing this a long long time).
>I agree they make sense but I really don't think we have them yet.
No but that is why we have these conversations. Years ago, we needed
a means to distribute technical documents. Now we have that.
<snip />
>If you support modularity in any kind of extensible way, you quickly
>move from having "a document format" to supporting structured content
>with arbitrary content models in an extensible way.
That was the SGML dream anyway. It has morphed but whereas it used
to have fins and gills, now it has legs and lungs. Meanwhile, PDF
is turning into a dolphin.
People believe everyone believes in standards. In my career, I have
often come up against IT shop managers that look back at me and say,
"I don't care. We do things here our own way because we have special
requirements." One reason I am not in sales or marketing is a lifelong
bad habit of pointing out that might not be true if they take the time
to look at the requirements and the possible standard solutions. That
is why I am locked up and never allowed to talk to customers. I'm crazy.
Perhaps I am. I took this job and that says a lot.
>To move to this model my assertion is that you have to specify certain
>things about the content format in a way that allows the application to
>deal with it. You have to specify:
> - how it looks on screen
> - maybe how it looks in print
> - what content model is valid for the format
> - maybe how the editing experience looks/functions
and as Mike points out, can one embed live data objects in it.
len
|
