scott said:
> I hate to leave issues hanging,
> but in your case I make an exception.
no problem, scott.
i'll have an annotation app out soon,
so thad won't be left hanging for long.
***
jon said:
> You have not stated *why* you believe your plain text solution
> is superior to XML for this particular application.
sorry, i thought i've said that too many times to repeat again.
a plain-text solution is superior to x.m.l. because it frees people
from the hassle of doing markup. fewer costs, equivalent benefits.
fairly straightforward...
> You've only dissed the XML approach w/o going into detail
> of how your plain text approach will sufficiently solve
> the external annotation of digital publications and meet
> all the important requirements as we understand them now.
first of all, i haven't "dissed" the x.m.l. approach.
if somebody can present me an x.m.l. solution that works,
and is perfectly transparent to users, i'll be happy as a clam.
what i have pointed out, respectfully, is that
acronyms are not solutions. the feeling here
seems to be that "x.m.l. can do that" is an answer.
it's not. if x.m.l. can truly do something, give people
a straightforward answer about _how_ to do it...
i know people who do tech support for software companies.
they are constantly having to deal with the expectations that
were falsely raised by the marketing department that says
"oh sure, our software can do that" simply to close the sale.
then, when the customer (rightfully) expects the software to
"do that", they are in for the surprise of their life, because
-- although the software _can_ do that -- it usually requires
a very expensive person (or even a whole crew) to work it.
you're doing the same kind of bait-and-switch to people here.
everyone gets the _impression_ that x.m.l. is all-powerful,
but x.m.l. actually never gets around to doing anything at all!
i hope thad, the original poster, will correct me if i'm wrong,
but i don't believe he came here asking about what kind of
core methodology he could use that would "eventually" let him
"write some scripts" or "build an application" to do annotations.
he wants to do annotations now, and wants a way to do them
that doesn't involve a lot of unnecessary work to implement.
the specific task that he has in mind is writing the annotations,
not creating an annotation system.
believe me, if x.m.l. delivered even _one-fifth_ of its promises,
i'd be one of its biggest supporters. but so far it's 95% vapor.
and let us not forget that, in order to start milking benefits,
_first_ we have to mark up the entire library, and i must again
remind people that little progress is happening on that front...
> So far, all you've implied is "Trust me, *I'm* building a tool"
wrong. my saying is "the proof is in the pudding".
i'm not asking anybody to trust anybody. be skeptical!
when my annotation program is ready, i will let you know.
and i "trust" that when your system is ready, you'll tell me.
and i "trust" the lurkers will notice who finishes first, and
finishes best, and which system is more robust and powerful
and cost-efficient and end-user friendly and all that good stuff.
> You are being disingenous by implying "they"
> (the XML experts) haven't done it because it can't be done.
wrong.
it _can_ be done in x.m.l.
the degree of difficulty is
higher than with plain-text.
but it's _eminently_ doable.
nothing is that difficult in this arena.
this ain't putting a man on the moon.
it's basically a note-taking application.
what i _am_ curious about, though,
is why it hasn't been done already?
you'd think that with the huge number of people
running around saying "x.m.l. is the solution" that
_somebody_ would've put a bell on this cat by now.
perhaps that degree of difficulty is higher than we think.
> The people who authored XML included
> a large number of *experienced* software
> developers who would eat your lunch.
when they finally write an annotation app,
show me their program! if it works well,
i'll buy 'em beer to go along with my lunch,
and take 'em to the strip club that evening...
-bowerbird