Suggestions for developing a publishing system??

McGintyMcGoo

Greetings

I am investigating a project for a publication that will include:

• A database to store all of the content
• A windows client for editing the data
• Multiple publishing options (website, data export for importing into DTP software, PDA etc)

Most of the above is fine when you treat the data as pure data. However, when it comes to applying styles and formats, things get a bit trickier (if that's a word). I'm fine with applying CSS styles to paragraphs of data, but what about individual words within paragraphs of data. In my eyes, the only way to control this is to store at least some of the formatting within the data fields themselves as some sort of style tag.

The problem here is that, for example, the PDA would not want to see these extra tags. My question is: Would you store one master set of data with tags included and then strip them out for whatever output medium does not need them, or store two sets of data (with and without tags), or does anyone alse have any other ideas and suggestions?????

Cheers

McGintyMcGoo

sean_or99

There are different ways to do this. This would be the method I would choose. (until someone mentions something better!).

You should store all your data in some XML format. As you put it some “master” XML doc type. Then you will need to write an xsl style sheet for each format you need to output. It then becomes a simple process of doing a xsl transformation depending on output.

The Corinthian

sean_or99 wrote:

You should store all your data in some XML format. As you put it some “master” XML doc type. Then you will need to write an xsl style sheet for each format you need to output. It then becomes a simple process of doing a xsl transformation depending on output.

I’m afraid that that strategy has been tried and it’s more trouble than it’s worth. I designed and wrote much of the CMS to a mobile portal on this principle, back in 2000. We found that the differences in layout and capabilities of different devices were such that we, more often than not, needed to add ‘hacks’ at the application layer to make the transformed XML viable. Of course, that’s not to say that you can’t use XML, just that it has its limitations.

Having developed a few of these I’ve come to the conclusion that abstracting the business logic of the content (in ActiveX, Beans, classes, PEAR, function libraries, whatever) so that they can be utilized in scripts that concern themselves only with the presentation layer, is probably the most efficient solution.

If you intend to develop on numerous handheld devices, you might want to take a look at the WURFL.

sean_or99

The Corinthian wrote:

I’m afraid that that strategy has been tried and it’s more trouble than it’s worth.

Are you sure? It didn’t work for you; while XSLT languages have a steep learning curve, it obviously works for the people at the WURFL project.

WURFL XSLT Tools

and for pretty much thousands of people who need to do XML transformations. I think coding everything up in c, or java or whatever to transform xml docs will work, just didn’t think anyone would seriously consider doing it that way.

The Corinthian

sean_or99 wrote:

Are you sure? It didn’t work for you; while XSLT languages have a steep learning curve, it obviously works for the people at the WURFL project.

Do you actually know how the WURFL works? It’s not using XML in the way you suggested, but using it as a repository of capabilities so that you can use that information in the manner I already suggested in my previous post.

sean_or99

The Corinthian wrote:

Do you actually know how the WURFL works? It’s not using XML in the way you suggested, but using it as a repository of capabilities so that you can use that information in the manner I already suggested in my previous post.

Do you know how XML works?

This is (I think) a topic about exporting data in different ways; exporting data to html, DTP (Desktop Publishing) and PDAs and maybe other different sources and the best way to do it. While even the people at WURLF have been utilising XSLs its pretty clear that XML transformation is really standard stuff by now. If you learn how to utilise XSLT, XQuery, XPath and so on, if you actually work as a programmer, then it will it will make things allot simpler for you when dealing with XML.

In reality the topic at hand could be solved by utilising the open document standard. You can already use XSL to transform the files in the opendoc format to XHTML and WML and PDF. However there are numeous issues with doing it this way. While for data transfer XML is pretty much essential the opendoc format is complex to say the least.

The Corinthian

sean_or99 wrote:

Do you know how XML works?

Yes. Apparently better than you seeing as you can’t see a difference between how you suggested how XML should be utilized in your first post and how the WURFL actually does so.

I gave my opinion, and you responded by arguing that WURFL uses XML. So what? My name appears on on the WURFL file, so I’m quite aware of it.

However I already stated that while there’s no reason to reject the use of XML, it does have its limitations and (from considerable experience) simply formatting output to suit the device using style sheets is one of them.

rsynnott

Since you're talking mobile devices, whatever solution you choose should transfer as little data as possible per article.

sean_or99

The Corinthian wrote:

Yes. Apparently better than you seeing as you can’t see a difference between how you suggested how XML should be utilized in your first post and how the WURFL actually does so.

I gave my opinion, and you responded by arguing that WURFL uses XML. So what? My name appears on on the WURFL file, so I’m quite aware of it.

However I already stated that while there’s no reason to reject the use of XML, it does have its limitations and (from considerable experience) simply formatting output to suit the device using style sheets is one of them.

Yes, coding everything up in c, java or whatever will work. XML has its limitations, not sure what you mean by that (maybe you are refereeing to some parsers?); but in terms of data transfer if you are not utilising XML and taking advantage of XML technologies then your doing something very wrong; as I have already pointed out even the people at WURFL utilise this approach. Writing functions to output data for different devices just seems very amateurish to me.

I am dealing with the OTA standard at the moment, and if the XML outputted from one of my stylesheets didn’t suit one of the suppliers expected format, that’s not a failing of XML, that’s a failing that I haven’t coded the stylesheet properly!

rsynnott

sean_or99 wrote:

Writing functions to output data for different devices just seems very amateurish to me.

Why, precisely? People have been doing it since the 50s. It works. It is often a reasonable approach, especially if one of your target devices is not amenable to XML.

sean_or99

rsynnott wrote:

Why, precisely? People have been doing it since the 50s. It works. It is often a reasonable approach, especially if one of your target devices is not amenable to XML.

Yes it will work. It’s up to the individual to program how he or she wants. But my assumption is you don’t have computing degree, because its pretty much hammered into you that computer science is an area that is constantly evolving; and if you are not continually retaining to utilise the best approaches out there, you are making life allot more difficult for yourself, and others who may have to work with your code. This is just a fact of the industry.

You seem to be under the impression that if you have an XML doc and you transform it that it has to be transformed into XML, that’s not the case at all. You can transform it into whatever text format you want.

rsynnott

sean_or99 wrote:

You seem to be under the impression that if you have an XML doc and you transform it that it has to be transformed into XML, that’s not the case at all. You can transform it into whatever text format you want.

Yes, I realise that. Are you talking about transforming it on the server, or on the client device? Using it as a backend markup is fine, though not always, IMO, particularly helpful. Sending it to a device in the expectation that that device can do the relevant transforms is not; you may be asked to support devices which can't do that.

sean_or99 wrote:

Yes it will work. It’s up to the individual to program how he or she wants. But my assumption is you don’t have computing degree, because its pretty much hammered into you that computer science is an area that is constantly evolving; and if you are not continually retaining to utilise the best approaches out there, you are making life allot more difficult for yourself, and others who may have to work with your code. This is just a fact of the industry.

Using XML just for the sake of it, because it's a buzzword, is foolish. If you can show a case where it'll be helpful, by all means use it there, but do not assume that it is always the best option.

Hobbes

XML has a time and a place. Data storage is not one of them.

IEEE did a very good article on it some time back about the major things that XML should never be used for but some in the industry go and do it anyway.

http://www.sdmagazine.com/documents/s=7726/sdm0212b/sdm0212b.htm

sean_or99

rsynnott wrote:

Yes, I realise that. Are you talking about transforming it on the server, or on the client device? Using it as a backend markup is fine, though not always, IMO, particularly helpful. Sending it to a device in the expectation that that device can do the relevant transforms is not; you may be asked to support devices which can't do that.

My reading of the topic was a project where data needs to be PUBLISHED in different formats.. There is data in a db, that needs to be exported in different ways depending on the type of file that needs to be exported all done through some windows programs. The data needs to have some sort of formatting tags encoded in it like CSS.

(Now that I think of it just keeping the initial data as XHTML and using transformers to output in different ways is a good way to do it. Code for modifying that multimedia content is essential though.)

You seem to think it’s something to do with mobile phones transforming xml data or nokia or Motorola or whatever, another poster thinks it’s about xml data storage????

rsynnott wrote:

Using XML just for the sake of it, because it's a buzzword, is foolish.

Oh please…. Is such a regular occurrence on the web that when someone mentions a technology and someone else isn’t familiar with it, that the standard comeback is, that’s a “buzzword”.

OK, I have hijacked this topic. Crap.

rsynnott wrote:

If you can show a case where it'll be helpful, by all means use it there, but do not assume that it is always the best option.

I think we are defiantly on different topics.

My opinion is that you are on about having some application and are trying to get some java file to run on a siemens C60 and you also have to create a separate application to get it working on the Motorola V Series and so on. Is this what you are on about? Are you on about apps written in the J2ME or something like that?

If so yes it’s a very non standardised industry and in a complete mess. Multiple versions of the same application have to be written for different phones. But for clarity start another topic on the mess that programming for mobile phones is in.

The Corinthian

sean_or99 wrote:

XML has its limitations, not sure what you mean by that (maybe you are refereeing to some parsers?); but in terms of data transfer if you are not utilising XML and taking advantage of XML technologies then your doing something very wrong

I’m not disagreeing with the use of XML for data transfer - I never suggested that. I am disagreeing with the ‘one XML content file fits all’ strategy of using style sheets to suit all client types. At worst it does not work, at best it’s grossly inefficient.

as I have already pointed out even the people at WURFL utilise this approach. Writing functions to output data for different devices just seems very amateurish to me.

You pointed out that they were using XML, but not in the manner that you originally suggested, so I don’t see your point.

I am dealing with the OTA standard at the moment, and if the XML outputted from one of my stylesheets didn’t suit one of the suppliers expected format, that’s not a failing of XML, that’s a failing that I haven’t coded the stylesheet properly!

OTA is not a good example as we’re discussing publishing, not provisioning. For example, say you want to publish content for Web, WAP (1.x, 2) and SMS. Other than content potentially being different (alternate lengths, images, etc.), in the case of Web and WAP navigation can be drastically different as what will work on the WWW is often not terribly user friendly on a handheld.

But my assumption is you don’t have computing degree, because its pretty much hammered into you that computer science is an area that is constantly evolving;

With respects, some of us have been in this game long before XML was around, so your point is moot.

This is just a fact of the industry.

Don’t confuse fact with hype.

sean_or99

The Corinthian wrote:

I’m not disagreeing with the use of XML for data transfer - I never suggested that. I am disagreeing with the ‘one XML content file fits all’ strategy of using style sheets to suit all client types. At worst it does not work, at best it’s grossly inefficient.

OK, you don’t believe me.

XSL is a family of recommendations for defining XML document transformation and presentation.

From http://www.w3.org/Style/XSL/

The Corinthian wrote:

You pointed out that they were using XML, but not in the manner that you originally suggested, so I don’t see your point.

The WURFL information is stored in XML. So the simpliest way to manipulate and transformm WURLF is XSLT.
If you have ideas or own XSLT, your help is welcome

http://wurfl.sourceforge.net/xslt/index.php

The Corinthian wrote:

OTA is not a good example as we’re discussing publishing, not provisioning. For example, say you want to publish content for Web, WAP (1.x, 2) and SMS. Other than content potentially being different (alternate lengths, images, etc.), in the case of Web and WAP navigation can be drastically different as what will work on the WWW is often not terribly user friendly on a handheld.

Finally something I agree with. Yes WML is a pretty broken and rather unless language and to convert HTML to WML is not merely going to be solved by style sheets.

But have you never used http://cocoon.apache.org/ ?

If you had utilised that framework based on XML and it would have allowed you to publish in WML, HTML, PDF… !

The Corinthian wrote:

With respects, some of us have been in this game long before XML was around, so your point is moot.

Don’t confuse fact with hype.

Yes, I have been going on about XML like its gods gift to the programming world and it’s not at all.

With respect if you are not prepared to retrain, not simply regarding learning XML, that doesn’t matter, but with the dynamic changes of the computing industry, then I pity the people who have to go through your code.

While many fundamental principals may stay the same the computing industry is not static.

rsynnott

sean_or99 wrote:

With respect if you are not prepared to retrain, not simply regarding learning XML, that doesn’t matter, but with the dynamic changes of the computing industry, then I pity the people who have to go through your code.

I have learned XML, and am quite comfortable with it. I see no reason, though, to go to massive trouble to make it fit situations which can quite happily be covered by far simpler solutions. XML is useful, but it is not a coverall.

0utshined

rsynnott wrote:

Why, precisely? People have been doing it since the 50s. It works. It is often a reasonable approach, especially if one of your target devices is not amenable to XML.

sean_or99 wrote:

Yes it will work. It’s up to the individual to program how he or she wants. But my assumption is you don’t have computing degree...

Could you answer his question maybe? I'd be interested in your response rather than a tangent.

Also, having a Comp. Sci. degree does not magically imbue you with a superior insight into problems. Just FYI.

sean_or99

rsynnott wrote:

I have learned XML, and am quite comfortable with it. I see no reason, though, to go to massive trouble to make it fit situations which can quite happily be covered by far simpler solutions. XML is useful, but it is not a coverall.

Well obviously.

The Corinthian

sean_or99 wrote:

OK, you don’t believe me.

XSL is a family of recommendations for defining XML document transformation and presentation.

From http://www.w3.org/Style/XSL/

What idiocy is this? Just because it says that in the introduction of the specification does not mean that’s how it actually works in the real world, in every situation.

The WURFL information is stored in XML. So the simpliest way to manipulate and transformm WURLF is XSLT.
If you have ideas or own XSLT, your help is welcome

This use of XML is completely different to your suggestion of how XML should be used in conjunction with a “need to write an xsl style sheet for each format you need to output”. So please do not change the goalposts.

Finally something I agree with. Yes WML is a pretty broken and rather unless language and to convert HTML to WML is not merely going to be solved by style sheets.

But have you never used http://cocoon.apache.org/ ?

Yes, and that doesn’t do it competently either.

With respect if you are not prepared to retrain, not simply regarding learning XML, that doesn’t matter, but with the dynamic changes of the computing industry, then I pity the people who have to go through your code.

While many fundamental principals may stay the same the computing industry is not static.

With respect, don’t try to teach grandma how to suck eggs. I suspect I’ve been using XML and XSL a quite a bit lot longer than you (and am, as I’ve already mentioned, one of the original contributors to the WURFL) and I find it a bit ridiculous that you are suggesting that.

sean_or99

The Corinthian wrote:

What idiocy is this? Just because it says that in the introduction of the specification does not mean that’s how it actually works in the real world, in every situation.

How idiotic is it for you to write, "I’m afraid that that strategy has been tried and it’s more trouble than it’s worth." In effect, I have tried it, it didn’t work, and it must never have worked for anyone!

The Corinthian wrote:

This use of XML is completely different to your suggestion of how XML should be used in conjunction with a “need to write an xsl style sheet for each format you need to output”. So please do not change the goalposts.

They are writing different style sheets to format the output of WURLF, and one of the reasons they call it the easiest approach is because it’s so generic.

The Corinthian wrote:

Yes, and that doesn’t do it competently either.

With respect, don’t try to teach grandma how to suck eggs. I suspect I’ve been using XML and XSL a quite a bit lot longer than you (and am, as I’ve already mentioned, one of the original contributors to the WURFL) and I find it a bit ridiculous that you are suggesting that.

Cocoon doesn’t do it? I had to utilise it once and will have to use it again soon, and since WML is so unpopular it saved me having to deal with all that card nonsense and its good that it is being phased out. But you are writing about how that an XML based approach cannot be transformed into multiple different formats, like HTML, XHTML, WML, PDF and so on that this approach doesn’t exist and cant work; and that exactly contradicts what is happening in reality!

Apache Cocoon, often just called Cocoon, is a web development framework built around the concepts of separation of concerns and component-based web development. The framework focuses on XML publishing and is built using the Java programming language. The flexibility afforded by relying heavily on XML allows rapid content publishing in a variety of formats including HTML, PDF, and WML. A powerful content management system, Apache Lenya, has been created on top of the framework. Cocoon is also commonly used as a data warehousing tool or as middleware for transporting data between systems.

http://en.wikipedia.org/wiki/Apache_Cocoon

Introducing Apache Cocoon

The XML Hype

Everybody talks about XML. XML here, XML there. All application servers support XML, everybody wants to do B2B using XML, web services using XML, even databases using XML.

Should you care about it? Given the amount of hype, you can't afford to go around ignoring XML, for that would be like ignoring the World Wide Web 10 years ago: a clear mistake. But why is this so for XML? What is this "magic" that XML seems to have in solving your problems? Isn't this another hype to change once again the IT infrastructure that you spent so much time implementing and fixing in the last few years? Isn't another way to spill money out of your pockets?

If you ever asked yourself one of the above questions, this paper is for you. You won't find singing-and-dancing marketing hype, you won't find boring and useless feature lists, you won't find the usual acronym bombing or those good looking vaporware schemas that connect your databases to your coffee machines via CORBA or stuff like that.

.....

XML Transformations

This was the point where Stefano was more or less two years ago for java.apache.org: I could use XML and define my own semantics with <sidebar>, <news>, <status> and all that and I'm sure people would have found those XML documents much easier to write (since the XML syntax is very similar to the HTML one and very user friendly)... but I would have moved from "all browsers" to "no browser".

And having documentation that nobody can browse is totally useless.

The turning point was the creation of the XSL specification which included a way to "transform" an XML page into something else. (It's more complex than this, but, again, I'll skip the technical details).

So now you have:

XML page ---(transformation)--> HTML page
                    ^
                    |
          transformation rules

that allows you to write your pages in XML, create your "graphics" as transformation rules and generate HTML pages on the fly directly from your web server.

Apache Cocoon 1.0 did exactly this.

http://cocoon.apache.org/2.1/introduction.html

Look into http://forrest.apache.org/, or http://sourceforge.net/projects/modxslt and so on…

The Corinthian

sean_or99 wrote:

How idiotic is it for you to write, "I’m afraid that that strategy has been tried and it’s more trouble than it’s worth." In effect, I have tried it, it didn’t work, and it must never have worked for anyone!

I was referring to your citing of a completely irrelevant line from the XML spec that proved nothing outside of your capacity to copy and paste the first line of the spec’s introduction.

My comment was, on the other hand, a direct response to the original poster.

They are writing different style sheets to format the output of WURLF, and one of the reasons they call it the easiest approach is because it’s so generic.

But that’s not the application of XSL you suggested in your original post! Do you know the difference or are you actively attempting to change the goalposts?

Cocoon doesn’t do it? I had to utilise it once and will have to use it again soon, and since WML is so unpopular it saved me having to deal with all that card nonsense and its good that it is being phased out.

That ‘card nonsense’ is not going to be phased out for a while and so if you ignore it you’re going to be outputting less than optimised WML for a large chunk of the devices out there.

Your solution seems to be to ignore such issues and hope the user is happy with the LCD approach.

But you are writing about how that an XML based approach cannot be transformed into multiple different formats, like HTML, XHTML, WML, PDF and so on that this approach doesn’t exist and cant work; and that exactly contradicts what is happening in reality!

I didn’t say it can’t be done, I said it’s more trouble than it’s worth. It’s an approach that can work in certain circumstances, but the idea of “one XML document fits all” runs into trouble very quickly.

Card structure is one issue that I could point at, but lets' not ignore possible business rules too that would require significantly different content for one device and another. Then we have the question of personalization; which leads us down the road of mixing more traditional Web technologies with XSL transformation - at worst a dirty hack, at best raising the question of why you’re bothering to overcomplicate the application in the first place.

As for the rest of your post, it seem to be little more than you copying and pasting other people’s work, without actually determining how they back up what you’re saying.

0utshined

sean_or99 wrote:

How idiotic is it for you to write, "I’m afraid that that strategy has been tried and it’s more trouble than it’s worth." In effect, I have tried it, it didn’t work, and it must never have worked for anyone!

Reread the lines you've quoted. He didn't say it didn't work he said it was more trouble than it was worth, implying there are easier ways. He is giving the OP the benefit of his experience which they are free to take or disregard.

sean_or99 wrote:

But you are writing about how that an XML based approach cannot be transformed into multiple different formats, like HTML, XHTML, WML, PDF and so on that this approach doesn’t exist and cant work; and that exactly contradicts what is happening in reality!

Actually he was writing about a possible solution to the OP's problem,as were you, until you dragged this thread off course.

TempestSabre

You'll probably think I'm barking but why not use an existing document format, as used by OpenOffice or MS Word. Use the native apps to create and edit the content, and store the their document format in your database, blobs or whatever. Then use the scripting tools, macro language in the native applications to manage the content, upload download publish etc. I've done this in the past and it was relatively easy to publish from word (for example) to PDF or to XML and script simple tools to import/export data as you like. Bit of a Frankeinstein sure. But its easier, than writing the whole thing yourself. Less elegant and brutish. Most programmers will hate it. But it can be a cheap and cheerful way to achieve a lot of functionality, especially with regard to complex formatting with relatively little effort.

The DTP angle is trickier as printing (for print) from PDF or from other formats like Word is difficult because few printer/print shops will handle that at reasonable cost. In truth they have enough problems EPS files. Then you have your import problem. Sure you can export xml for inport into apps like Quark or InDesign but you end up with a lot of manual work to work with it, or get it back as it was intended. On one project we copied the house style of the complex DTP layouts in Word, used it for electronic publishing only and kept the print work seperate. We could probably have tied it up with inDesign but the resources available didn't allow that.

sean_or99

The Corinthian wrote:

I was referring to your citing of a completely irrelevant line from the XML spec that proved nothing outside of your capacity to copy and paste the first line of the spec’s introduction.

My comment was, on the other hand, a direct response to the original poster.

But that’s not the application of XSL you suggested in your original post! Do you know the difference or are you actively attempting to change the goalposts?

That ‘card nonsense’ is not going to be phased out for a while and so if you ignore it you’re going to be outputting less than optimised WML for a large chunk of the devices out there.

Your solution seems to be to ignore such issues and hope the user is happy with the LCD approach.

I didn’t say it can’t be done, I said it’s more trouble than it’s worth. It’s an approach that can work in certain circumstances, but the idea of “one XML document fits all” runs into trouble very quickly.

Card structure is one issue that I could point at, but lets' not ignore possible business rules too that would require significantly different content for one device and another. Then we have the question of personalization; which leads us down the road of mixing more traditional Web technologies with XSL transformation - at worst a dirty hack, at best raising the question of why you’re bothering to overcomplicate the application in the first place.

As for the rest of your post, it seem to be little more than you copying and pasting other people’s work, without actually determining how they back up what you’re saying.

Yeah, copying and pasting is great.

If you write a CMS application in ALGOL, for god sake if you type in assembly into the cpu instruction pipe and hope that some commands are executed that will transform data into different formats! it might output pdfs, html, whatever text doc format blackberry or palm use, or even wml: Then if that WML doesn’t work on a Nokia 7250i, it has nothing to do with a failing/limitation of ALGOL, assembly, or c or java, or xml, or whatever. IT’S A FAILING THAT MOBILE PHONE VENDORS NEVER IMPLIMENTED THE TECHNOLOGY PROPERLY!

Wurfl will help you get around allot of these problems, but trying to get a list box to display on more than 3 different phone types is miracle in itself.

Now it makes perfect sense when reading your stuff if you are writing about some separate piece of software, that’s not a cms, nor will it export data in different formats or do any of that stuff. What you are writing about is some webserver application that displays slightly different WML depending on phone types. So that you dont get data transformations in which ever way it can be done is understandable because you are only going to be using one text based format anyways.

So ignoring that area of data transformation issue, the obvious choice to do what was initially alluded to. Strip out all those tags that are simply not cross phone compatible. You don’t want to use images, or tables, or forms, just text and links that’s it. Anything else and you will need a separate application and you are also costing whoever is visiting the wap site a small fortune depending on how much you are exporting to be viewable over GPRS. And since it is so unreliable then the less you export the better. Operators do charge on per kilobyte basis!

WML is not XHTML, PDF, RTF, SVG, OpenDoc or any text based format that has been even fractionally standardised.

The Corinthian

sean_or99 wrote:

Yeah, copying and pasting is great.

It’s better if you understand what you’re copying and pasting.

Wurfl will help you get around allot of these problems, but trying to get a list box to display on more than 3 different phone types is miracle in itself.

Why would you want to use a list box?

Now it makes perfect sense when reading your stuff if you are writing about some separate piece of software, that’s not a cms, nor will it export data in different formats or do any of that stuff. What you are writing about is some webserver application that displays slightly different WML depending on phone types.

Why did you discuss that “separate piece of software, that’s not a cms, nor will it export data in different formats or do any of that stuff” in your first post then?

So ignoring that area of data transformation issue, the obvious choice to do what was initially alluded to. Strip out all those tags that are simply not cross phone compatible. You don’t want to use images, or tables, or forms, just text and links that’s it. Anything else and you will need a separate application and you are also costing whoever is visiting the wap site a small fortune depending on how much you are exporting to be viewable over GPRS. And since it is so unreliable then the less you export the better. Operators do charge on per kilobyte basis!

Ahhh... the LCD strategy. Still doesn’t exonerate the XSL approach you originally suggested (and that you’re now mysteriously quiet on).

WML is not XHTML, PDF, RTF, SVG, OpenDoc or any text based format that has been even fractionally standardised.

It has, but as you already pointed out, it’s not been implemented in a standard fashion. The same could have been said of HTML five years ago, until IE became so dominant to make the entire debate moot.

Part of the job of a good developer is - resources allowing - to adapt your application to all the platforms that it is expected to run on. Sometimes this will mean the LCD approach, for budgetary reasons; sometimes it’ll mean something far more comprehensive.

rsynnott

sean_or99 wrote:

Yeah, copying and pasting is great.

If you write a CMS application in ALGOL, for god sake if you type in assembly into the cpu instruction pipe and hope that some commands are executed that will transform data into different formats!

Parse error.

sean_or99

The Corinthian wrote:

It’s better if you understand what you’re copying and pasting.

Why would you want to use a list box?

Do display some sort of list, maybe?

The Corinthian wrote:

Why did you discuss that “separate piece of software, that’s not a cms, nor will it export data in different formats or do any of that stuff” in your first post then?

Ahhh... the LCD strategy. Still doesn’t exonerate the XSL approach you originally suggested (and that you’re now mysteriously quiet on).

LOL! OK, this is just getting too silly. You see I was going on about some sort of cms publishing system you were going on about something else, that’s why it has taken me 10 posts to work out your on about just mobile phones irrespective of anything else.

When someone is at the stage where they have to quote about projects or sources in use in industry today and someone responds with; the technology the project utilises doesn’t work, or is a myth, or they tried it and failed therefore everyone else must fail with it; truly that’s a spectacular level of stupidity. My copying and pasting skills, as they are, have gone to such a waste. Which is of course no big loss in this case.

The Corinthian wrote:

It has, but as you already pointed out, it’s not been implemented in a standard fashion. The same could have been said of HTML five years ago, until IE became so dominant to make the entire debate moot.

Part of the job of a good developer is - resources allowing - to adapt your application to all the platforms that it is expected to run on. Sometimes this will mean the LCD approach, for budgetary reasons; sometimes it’ll mean something far more comprehensive.

Do even start to give me advice about being a good developer. My programming skills are bad enough.

I mean your writing about having an adaptive application. All transformations done in XSLT ARE GENERIC! It’s writing all your transformations in something like .NET or PHP that ties those data transformations to a specific platform or webserver! That’s it, I’m done.

The Corinthian

sean_or99 wrote:

Do display some sort of list, maybe?

No, still can’t see your point.

LOL! OK, this is just getting too silly. You see I was going on about some sort of cms publishing system you were going on about something else, that’s why it has taken me 10 posts to work out your on about just mobile phones irrespective of anything else.

No, we’re discussing the same thing. Mobile devices are simply a good example of where the “one XML doc to suit all” approach is not a good one.

When someone is at the stage where they have to quote about projects or sources in use in industry today and someone responds with; the technology the project utilises doesn’t work, or is a myth, or they tried it and failed therefore everyone else must fail with it; truly that’s a spectacular level of stupidity.

No, as has been pointed out repeatedly by a number of people, I’ve not said it can’t be used, only that it’s not worth the effort. That you do it this way, I’ve no doubt, but it’s a methodology I’ve experience with and that I’ve come to the conclusion that it is inefficient and often limiting.

My copying and pasting skills, as they are, have gone to such a waste. Which is of course no big loss in this case.

Your copying and pasting skills, as they are, went to waste because you were not shedding anything new to the discussion.

I mean your writing about having an adaptive application. All transformations done in XSLT ARE GENERIC! It’s writing all your transformations in something like .NET or PHP that ties those data transformations to a specific platform or webserver! That’s it, I’m done.

Which returns us to the original question of why you’re bothering with XSLT if you have to add a traditional layer of business logic to get what you want? This is the same traditional layer of business logic, btw, that you earlier considered:

“Writing functions to output data for different devices just seems very amateurish to me.”

So instead of a traditional:

DB --> Server Side App --> Buffer

You’re suggesting a convoluted:

DB --> XSLT --> Server Side App --> Buffer

Hardly makes sense on the face of it, does it? But at least we can tell the client that we used XML :rolleyes:

rsynnott

The Corinthian wrote:

Hardly makes sense on the face of it, does it? But at least we can tell the client that we used XML :rolleyes:

Well, exactly! Stick on a blog, and it's Web 2.0!

sean_or99

The Corinthian wrote:

No, still can’t see your point.

No, we’re discussing the same thing. Mobile devices are simply a good example of where the “one XML doc to suit all” approach is not a good one.

At this point, this is just about mobiles unless there is something else.

The Corinthian wrote:

No, as has been pointed out repeatedly by a number of people, I’ve not said it can’t be used, only that it’s not worth the effort. That you do it this way, I’ve no doubt, but it’s a methodology I’ve experience with and that I’ve come to the conclusion that it is inefficient and often limiting.

Your copying and pasting skills, as they are, went to waste because you were not shedding anything new to the discussion.

Which returns us to the original question of why you’re bothering with XSLT if you have to add a traditional layer of business logic to get what you want? This is the same traditional layer of business logic, btw, that you earlier considered:

“Writing functions to output data for different devices just seems very amateurish to me.”

So instead of a traditional:

DB --> Server Side App --> Buffer

You’re suggesting a convoluted:

DB --> XSLT --> Server Side App --> Buffer

Hardly makes sense on the face of it, does it? But at least we can tell the client that we used XML :rolleyes:

INPUT FORMAT --> TRANSFORMATION --> OUTPUT FORMAT

Or

CONTENT -> APPLY STYLE -> CONTENT WITH APPLIED STYLE

OR

SEPERATING CONTENT FROM STYLE

Basic tutorial on this: http://nwalsh.com/docs/tutorials/xsl/xsl/slides.html

The Corinthian

sean_or99 wrote:

At this point, this is just about mobiles unless there is something else.

PDA’s and other handheld devices, for a start. Different browsers (and operating systems) too. Or is your idea of publishing “one size fits all”?

Let’s not forget the issue of customisation - for example a user logs in and is greeted with a personalised message or menu. Unless you start mixing XSLT with more traditional technologies (and if you do, it begs the question of why you’re bothering with the XSLT in the first place), how are you going to do it?

INPUT FORMAT --> TRANSFORMATION --> OUTPUT FORMAT

Or

CONTENT -> APPLY STYLE -> CONTENT WITH APPLIED STYLE

OR

SEPERATING CONTENT FROM STYLE

What have these got to do with the processes I described in my last point? You already admitted in your previous post that XSL transformations alone are generic - which frankly does not make for a very good CMS.

Basic tutorial on this: http://nwalsh.com/docs/tutorials/xsl/xsl/slides.html

I already know how it works, thank you - do you?