Sure, if they don't have the XML libraries installed they will, after all we
can't write them from scratch for them.

Mugur

--- Paul Baranowski wrote:
> Is it safe to assume that the current campsite client base has the PHP
> XML libraries installed so that I can use functions like:
>
> xml_parser_create()
>
> ???
>
> - Paul




__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

------------------------------------------
Posted to Phorum via PhorumMail

This is a multipart message in MIME format.
--=_alternative 002D72D8C1256EC8_=
Content-Type: text/plain; charset="us-ascii"

Hi folks,

I'd say the formats, in order of their importance, are:

1) NewsML (yes, it is overkill in terms of the number of possible metadata
tags, but it is also the most comprehensive for professional news work

2) RSS 2.0 (more flexible, and the tag will mean some
interesting things in the future)

3) RSS 0.91 (most widespread support. As John put it, the Lingua Franca of
syndication)

4) Atom (up-and-coming, but as far as I can tell, uptake is limited to the
Blogger A-list; we should support it, but the question is whether it needs
to be there for 2.2 or if it can wait)

I like John's idea of using XSLT to transform the feeds into whatever we
need; I'm not a developer (I just shake people's hands and hand out
business cards), but I'd bet there will be more of these syndication
formats to come, and if we can build flexibility into our architecture as
opposed to "hard-wiring" support for one format or another, I'd say we're
better off.

doug






John Pye
07/05/2004 04:06 AM
Please respond to campsite-dev


To: campsite-dev@campware.org
cc:
Subject: Re: [campsite-dev] Do clients have PHP XML libraries loaded?


I've just checked the Red Hat 9 binary RPM version of PHP 4.2.2, and
expat XML parser 1.95.5 is built-in in that version. FYI, that version
also includes the domxml extension, WDDX, and GD 1.6.2, amongst other
things. You might want to check the binary packages for other platforms.

JP

Paul Baranowski wrote:

> Is it safe to assume that the current campsite client base has the PHP
> XML libraries installed so that I can use functions like:
>
> xml_parser_create()





--=_alternative 002D72D8C1256EC8_=
Content-Type: text/html; charset="us-ascii"



Hi folks,



I'd say the formats, in order of their importance, are:



1) NewsML (yes, it is overkill in terms of the number of possible metadata tags, but it is also the most comprehensive for professional news work



2) RSS 2.0 (more flexible, and the <enclosures> tag will mean some interesting things in the future)



3) RSS 0.91 (most widespread support. As John put it, the Lingua Franca of syndication)



4) Atom (up-and-coming, but as far as I can tell, uptake is limited to the Blogger A-list; we should support it, but the question is whether it needs to be there for 2.2 or if it can wait)



I like John's idea of using XSLT to transform the feeds into whatever we need; I'm not a developer (I just shake people's hands and hand out business cards), but I'd bet there will be more of these syndication formats to come, and if we can build flexibility into our architecture as opposed to "hard-wiring" support for one format or another, I'd say we're better off.



doug

John Pye <john@curioussymbols.com> 07/05/2004 04:06 AM Please respond to campsite-dev

To:        campsite-dev@campware.org         cc:                 Subject:        Re: [campsite-dev] Do clients have PHP XML libraries loaded?

I've just checked the Red Hat 9 binary RPM version of PHP 4.2.2, and

expat XML parser 1.95.5 is built-in in that version. FYI, that version

also includes the domxml extension, WDDX, and GD 1.6.2, amongst other

things. You might want to check the binary packages for other platforms.



JP



Paul Baranowski wrote:



> Is it safe to assume that the current campsite client base has the PHP

> XML libraries installed so that I can use functions like:

>

> xml_parser_create()










--=_alternative 002D72D8C1256EC8_=--

------------------------------------------
Posted to Phorum via PhorumMail

More about the reason for scenario (1)? Is it just so that writers can
work offline?



If you just want to import basic formatted text (bold, italic, etc) you
can import HTML generated by Word, then transform it to the syntax you
require using XSLT after the file is uploaded. (You could do direct
transformation of uploaded OpenOffice files (*.sxw) cause they are
already in zipped XML form.) Mozilla Composer is another tool to think
about as well, for composing HTML.



If you want to import more complex stuff then maybe you need to set up
your users with an XML editor. I used to use XML Spy and some other
ones a while back; there are some very espensive/impressive pieces of
software out there (eg href="http://www.arbortext.com/products/ee_close_up.htm">Arbortext),
but recently some open source alternatives have appeared. Pollo was the
most robust I could find with a quick survey.

http://pollo.sourceforge.net/

http://www.xerlin.org/



My experience with getting writers to work with XML was that
non-programmers don't handle any XML very well, and it's best to give
them a tool to help them, but even then they might struggle.



XSLT does have the potential to help in article upload. You could
hard-code for NewsML import, then transform any uploaded Atom content
into something that NewsML can understand. Probably you could implement
a subset of NewsML, eg ignore all the audio/video stuff. Or maybe Atom
is indeed adequate.



JP



Paul Baranowski wrote:

The feature that I am developing is for import of articles.  You might
be thinking of article export from your comments below - for example,
XSLT only helps us for article export.  RSS 0.91 and 2.0 do not support
content, so it cannot be used for article import.  We could use the
optional mod_content tag for RSS and use that for article import if we
wanted, but I'm not sure how well this is supported.  The new
"enclosure" tag in RSS 2.0 only points to external files, and does not
contain data itself.



If anyone can provide me with more use case scenarios, it would greatly
help the development of this feature.  As far as I know, there are two:


1) Someone types up an article in the required format, or uses some
sort of software that automatically creates the format, and then
uploads the article to the server.

2) The campsite server reads a feed from another server and adds the
articles to its database.



Under scenario #1, NewsML might
be an incredibly daunting format for our users if they are typing it in
by hand.  That's why we were thinking of Atom - a
very simple format that can be written by hand and is being actively
developed. 



I understand that the feature should not be tied to a particular
format, and the code will be written so that new formats can be
implemented later.  



- Paul

------------------------------------------
Posted to Phorum via PhorumMail

Hi all,

It seems to me that NewsML would be much more useful than Atom but the issue is
Paul needs about a month to implement the feature + the Atom filter. If you
want the NewsML filter implemented first the deadline should be postponed and
Paul should let us know how much.

Mugur

--- Douglas.Arellanes@mdlf.org wrote:
> Hi Paul,
>
> I understand your question, and will try to give you a bit more feedback
> on the usage.
>
> 1) Manual input is kind of misleading because the vast majority of people
> will never actually create an article for automatic input "by hand," and
> will most likely use a Word macro (or its OpenOffice equivalent) to
> prepare their text, provided they use a template that is pre-formatted for
> them.
>
> 2) Article syndication will first be used in the SNOW project, where we
> know a few things about the users and their Campsite instances; because we
> are operating their hosting, we are in control of the Campsite version and
> all aspects of the server instance. While this may not be a huge
> advantage, we do know that the sites won't be using non-standard Campsite
> fields.
>
> 3) The issue of non-standard fields is one that may present problems for
> any of the syndication interchange formats. How will a user map the fields
> they have installed (and call from all their templates) to match the input
> coming from the syndication format, be it NewsML or Atom or whatever? I
> don't have a problem with Atom as our interchange format of choice, but I
> would much rather see us come up with a solution that is format-neutral
> when it comes to interchange. If Atom provides the best fit with standard
> Campsite fields, so be it. But ideally, what we come up with would be
> flexible enough to use any of the popular interchange formats. Besides, as
> I understand it, none of these formats map perfectly, so some shoehorning
> will be necessary.
>
> 4) The use scenario I have in mind is this: I would like to see Campsite
> provide integration with weblogs. Let's say a news site like TOL finds a
> weblogger they think is interesting, and want to syndicate their content.
> The problem is that the content as it's written on their weblog is too
> local and needs rewriting for TOL's audience. Because the content from the
> weblog is integrated into Campsite workflow - and I'm being deliberately
> vague on the mechanics of how this is done - editors can work on the text
> just as with any other "submitted" article. For me, what's key is that all
> of the content make it into Campsite.
>
> NewsML input is important because a couple of different clients have
> discussed the possibility of connecting their Campsites to a Reuters feed,
> which comes in NewsML. In this scenario, the incoming article would
> probably be marked automatically as "Published" and go straight out on to
> the site, otherwise the list of submitted articles would probably be too
> big.
>
> Other use scenarios that don't fit the typical article paradigm but could
> turn into important ones would be in commercial content: there are two
> uses that come to mind: one is classified ads (personals, job listings,
> real estate listings) that are created by a central site and carried by a
> number of sites, and the other, probably less likely one is a bookstore
> application (or maybe even the Digital Kiosk 2.0) that would provide
> ordering and product information directly to the Campsite server, and
> handle only the transaction.
>
> Out on the horizon a bit further into the future lies what Sava has
> referred to as "the Supercontentor" - essentially a Campsite-like
> application that would be at the core of a publication's print production.
> Many of the NewsML tags would probably find more use in that situation,
> but we'll have to take that as it comes.
>
>
> Hope this helps,
>
> doug
>
> =============================================
> Media Development Loan Fund
> =============================================
> Douglas Arellanes
> Head of Research and Development
> Center for Advanced Media--Prague (CAMP)
> Na vinicnich horach 24a/1834, 160 00 Prague 6
> Czech Republic
> Tel: + 420 2 3333 5356, Fax: +420 2 2431 5419
> Mobile: +420 724 073 364
> http://www.mdlf-camp.net
> http://www.campware.org
> =============================================
> http://www.mdlf.org
> =============================================
>
>
>
>
> Paul Baranowski
> 07/05/2004 07:14 PM
> Please respond to campsite-dev
>
>
> To: campsite-dev@campware.org
> cc:
> Subject: Re: [campsite-dev] Which format to use?
>
>
> The feature that I am developing is for import of articles. You might be
> thinking of article export from your comments below - for example, XSLT
> only helps us for article export. RSS 0.91 and 2.0 do not support
> content, so it cannot be used for article import. We could use the
> optional mod_content tag for RSS and use that for article import if we
> wanted, but I'm not sure how well this is supported. The new "enclosure"
> tag in RSS 2.0 only points to external files, and does not contain data
> itself.
>
> If anyone can provide me with more use case scenarios, it would greatly
> help the development of this feature. As far as I know, there are two:
> 1) Someone types up an article in the required format, or uses some sort
> of software that automatically creates the format, and then uploads the
> article to the server.
> 2) The campsite server reads a feed from another server and adds the
> articles to its database.
>
> Under scenario #1, NewsML might be an incredibly daunting format for our
> users if they are typing it in by hand. That's why we were thinking of
> Atom - a very simple format that can be written by hand and is being
> actively developed.
>
> I understand that the feature should not be tied to a particular format,
> and the code will be written so that new formats can be implemented later.
>
>
> - Paul
>
>
>
> Douglas.Arellanes@mdlf.org wrote:
>
> Hi folks,
>
> I'd say the formats, in order of their importance, are:
>
> 1) NewsML (yes, it is overkill in terms of the number of possible metadata
> tags, but it is also the most comprehensive for professional news work
>
> 2) RSS 2.0 (more flexible, and the tag will mean some
> interesting things in the future)
>
> 3) RSS 0.91 (most widespread support. As John put it, the Lingua Franca of
> syndication)
>
> 4) Atom (up-and-coming, but as far as I can tell, uptake is limited to the
> Blogger A-list; we should support it, but the question is whether it needs
> to be there for 2.2 or if it can wait)
>
> I like John's idea of using XSLT to transform the feeds into whatever we
> need; I'm not a developer (I just shake people's hands and hand out
> business cards), but I'd bet there will be more of these syndication
> formats to come, and if we can build flexibility into our architecture as
> opposed to "hard-wiring" support for one format or another, I'd say we're
> better off.
>
> doug
>
>
>




__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

------------------------------------------
Posted to Phorum via PhorumMail