[PP-main] Technical/implementation matters

[Joakim Ziegler]

On Mon, Mar 06, 2000 at 11:13:26AM +0930, Nick Lothian wrote:
>> I'd like to see this embedded in the same file as the actual content,
>> though. It's a lot easier, and less susceptible to network

> Do you want to include more than one story in a file? How does a client get
> a list of stories from a client?

More than one story? Yes, I don't see why not, it's quite easy to do, and
would be convenient in some cases. The list of stories can be done in several
ways: As a protocol thing (the way it's done in NNTP, when you get headers)
or as a virtual document (transferred in the same way as normal documents,
but as a response to a certain type of request). I have no strong opinions on
which one is the best, really, I haven't thought about that much, but my
intuition says "protocol", it feels more correct to me.

This is an interesting matter, separating the protocol from the format. Both
are needed, but the borde can be moved pretty far in each direction.


>> Yes, at least it will need *a* format. Plain text is insufficient, you'll
>> at least need the standard trappings of the journalist trade, like boldface,
>> italics, etc., and also a way to specify links. Maybe a simple table
>> syntax, and a way to reference images that go with the story (possibly
>> without setting the position in the text, though, that should be up to the
>> formatting on the site side).

> Ehw! You're right of course - we do need it, but it's going to be a
> significant barrier to people using the system - A publisher needs to write
> software needs to write to transform their stories to the format they use on
> their site, and to our format as well.

Yes. I've thought about this, and you're right, it's a barrier to entry. But
I don't see how it can otherwise be done, if we want the system to be
scalable and useful. I mean, we need to specify category and keyword options
globally as well, if not, searching and filtering is going to be impossible.
And this scheme is sure to clash with at least some of the systems people are
using at the moment. You can't do exchange of data in a completely
heterogenous environment, you need to convert to a common format. The
alternative is writing converters from every format to every format (n^2-n),
while this requires only converters between the common format and the formats
out there (n*2).

I don't think there's any other way of doing it. Is there?


> We don't want "boldface" and "italics", though - we want tags to define
> their meaning - otherwise you can bet people will start trying to use the
> tags to define the look of their stories.

Maybe, maybe not. Actual boldface and italics are about the limit of what
journalists are traditionally able to specify, and I don't see the damage in
those. The alternative would be something like <emphasis> and <strong>, which
will do more or less the same thing, and people would expect them to behave
in a certain way (ie. a de facto standard for representation).

I see another problem with detailed markup of what stuff is as well. It
requires the journalists to write in that format to begin with, since there's
no way to automatically add that markup info. In other words, to do that, you
need to move the internal storage format of your site over to this format
(which would be good if the format is good, but require extensive changes to
a lot of sites just so they could use this).

What do you guys think? Is it worth it? There are several degrees to which we
can do this, from the "These HTML tags are allowed" approach to the "Detailed
abstract markup" approach (I've been part of teams doing both, and both have
advantages and disadvantages).


> Isn't their already a XML linking syntax?

Yes, XLink. But it might be slightly overkill for our use. Then again, maybe
not.


> Of course it has to be XML - because the client sites need to be able to
> automatically format the stories to the look of their site.

Ideally, this would be done with XSL:T. But that standard isn't all that
finished and stable, and is a bit tricky. I can think of a few alternatives,
like the Python based system we're going to use in Conglomerate, but none
that make the transformation rules exactly *easy* to write.

-- 
Joakim Ziegler - simplemente r&d director - joakim at simplemente.net
 FIX sysop - free software coder - FIDEL & Conglomerate developer
      http://www.avmaria.com/ - http://www.simplemente.net/