Hopbot log for 2007-10-29 - Helma IRC channel: #helma on irc.freenode.net

2007-10-29:

[0:06] <jkridner> I get an error that the DbSource XYX does not exist.
[0:17] <doublec joined the chat room.
[0:19] <jkridner> it should be as easy as editing db.properties in my application's directory, right?
[0:20] <jkridner> xyz.url = valid JDBC URL
[0:20] <jkridner> xyz.driver = valid JDBC driver class in CLASSPATH
[0:20] <jkridner> xyz.user = valid database username
[0:20] <jkridner> xyz.password = valid database password for username
[0:20] <jkridner> Root/main.hac: getDBConnection("xyz");
[0:34] <peter_12 joined the chat room.
[0:48] <BSlivka> You could try restarting helma
[0:48] <BSlivka> sometimes that helps
[0:48] <BSlivka> or the specific application
[0:55] <jkridner> no difference in restarting.
[0:56] <jkridner> I'm new to JDBC, so I suspect I could be doing something wrong there.
[0:56] <jkridner> I wrote a simple Java app to test my JDBC connection and it seems fine.
[0:56] <jkridner> I'm using java.sql.Driver and java.sql.DriverManager.
[1:07] <peter_12 left the chat room.
[1:20] <BSlivka> I had some pain in getting this to work myself.
[1:21] <BSlivka> What you may want to try, is add helmatools.zip to your application's repository
[1:21] <BSlivka> that let's you choose datasources
[1:21] <BSlivka> rather
[1:21] <BSlivka> if you add sqlshell to the end of a url
[1:21] <BSlivka> it lets you select a datasource
[1:22] <BSlivka> or you could try it on the welcome application
[1:22] <BSlivka> Either way- it removes one variable from the equation, since you're testing with a helma app that was written to work with a correctly configured database
[1:22] <BSlivka> rather than two variables, where it could either be the database configuration, or the way you've written your app
[1:23] <BSlivka> then you can tweak until the datasource is working properly
[1:23] <BSlivka> then you'll know for sure whether it's the way you've written the code to access the DB
[2:20] <jkridner> k
[2:22] <jkridner> when I add sqlshell, I get "Error retrieving Nodes".
[2:23] <jkridner> I can get to 'sqlshell' through the welcome application.
[2:24] <BSlivka> Well, i think in retrospect it was a mistake for me to tell you to add sqlshell to your WIP application
[2:24] <BSlivka> go through sqlshell in the welcome application instead
[2:24] <jkridner> I can do that, but it doesn't provide any data sources.
[2:24] <BSlivka> if your db.properties is in the main helma dir, then if your datasource is configured correctly
[2:24] <BSlivka> it should list a datasource there
[2:24] <jkridner> k.
[2:24] <BSlivka> if it doesn't, then the datasource is not configured correctly
[2:24] <jkridner> restart helma?
[2:25] <BSlivka> You could try
[2:25] <BSlivka> yes
[2:25] <jkridner> no love.
[2:25] <BSlivka> if after you do that though, the datasource doesn't show,
[2:25] <BSlivka> you'll want to look at whether the jdbc driver is installed correctly- and it is since you got a java application to work
[2:26] <jkridner> oh, wait...
[2:26] <jkridner> I got something...
[2:26] <jkridner> I had it in the apps directory, instead of the directory above.
[2:26] <BSlivka> Ah
[2:26] <BSlivka> main helma dir!
[2:26] <BSlivka> it can also go inside an app dir
[2:27] <jkridner> the list is there now, but selecting either now gives a "Sorry, data source XYZ is not defined for this application."
[2:28] <BSlivka> It could be that now it sees that you've defined a datasource
[2:28] <BSlivka> but one or more of the datasource parameters is wrong
[2:29] <BSlivka> I was going to say, to check that the driver is properly on the classpath, such that helma can see it
[2:29] <jkridner> I'm using the same classpath as i had for my test java application.
[2:29] <BSlivka> you can be 100% sure of this by putting it in helma's lib/ext directory
[2:30] <jkridner> I can see jdbc-mysql.jar and jdbc-postgresql.jar in the CLASSPATH.
[2:31] <BSlivka> what's the string you have for >xyz.driver?
[2:32] <jkridner> com.mysql.jdbc.Driver for MySQL and org.postgresql.Driver for PostgreSQL.
[2:32] <jkridner> I've been trying both to try to get one to work.
[2:35] <jkridner> XYZ.url = jdbc:mysql://localhost/test
[2:36] <BSlivka> Have you tried putting jdbc-mysql.jar or jdbc-postgresql.jar in lib/ext?
[2:37] <jkridner> no.
[2:38] <jkridner> strange.? that seems to have worked.
[2:39] <jkridner> the Sql Shell looks pretty nice.
[2:40] <jkridner> I'm confused though, since I checked the classpath before invoking ./start.sh several times.
[2:40] <jkridner> I love Java, but I REALLY hate the CLASSPATH.
[2:41] <jkridner> BSlivka: thanks for the help!
[2:42] <BSlivka> no worries
[2:42] <jkridner> any ideas why it doesn't pick up the CLASSPATH from the environment?
[2:42] <BSlivka> I think helma's classpath is different from the general java classpath
[2:42] <BSlivka> I'm not sure why that is
[2:43] <BSlivka> But it could be to keep the server environment light
[2:43] <BSlivka> and load only extensions that you explicitly tell it to
[2:43] <jkridner> sure, but I hate to make copys of every jar file I want to use...
[2:43] <jkridner> I guess I could get in the habit of soft linking.
[2:45] <BSlivka> in start.bat/sh
[2:45] <BSlivka> at the top
[2:45] <BSlivka> "rem To add jar files to the classpath, simply place them into the
[2:45] <BSlivka> rem lib/ext directory of this Helma installation."
[2:45] <BSlivka> So that seems to indicate that it's intentional
[2:45] <BSlivka> but still doesn't explain why
[2:46] <jkridner> I'll live with it.? I suppose it isn't that bad.
[2:46] <jkridner> I confirmed that softlinks work.
[2:47] <jkridner> And, I was able to remove my db.properties file from the helma root directory and put it only in my application.
[2:47] <jkridner> so, all works as "advertised".
[2:48] <jkridner> guess I was being stubborn and didn't realize it.
[2:49] <jkridner> I'll keep moving on the tutorial now.? Maybe next I'll figure out why I set res.data.title in the HAC file and read resource.title in the SKIN file.? Thanks again.
[2:52] <BSlivka> I can tell you that
[2:52] <BSlivka> It's because the skin file isn't in javascript
[2:52] <BSlivka> it's in a custom macro language
[2:53] <jkridner> but when you enter a <% %> region, shouldn't the variable names be constant?? I guess not, since they are macros of some kind.? Seems less than ideal to me.
[2:56] <BSlivka> the macro language gets transformed into equivilent javascript
[2:57] <BSlivka> but it really is different
[2:57] <jkridner> in your experience with Helma, does it all become rather intuitive or are we in the middle of trying to do some good cleanup?
[2:58] <jkridner> If I keep going with building my site using Helma, I'm sure I'll try to get more involved and contribute something back.
[3:02] <doublec> is there any basic weblogging software written using helma? For example, what powers the dev.helma.org weblog?
[3:03] <jkridner> doublec: in a quick look, I've seen antville.org
[3:03] <doublec> thanks, I saw antville too - I was wondering if that was what the helma site was using or not
[3:05] <jkridner> it shows up on the list of Antville sites: http://code.google.com/p/antville/wiki/AntvilleSites
[3:06] <doublec> thanks
[3:09] <BSlivka> Sorry was coding in helma, will answer questions once I read them.
[3:10] <BSlivka> I have only been doing helma for a couple weeks
[3:11] <BSlivka> but I will say something about intuitive.
[3:11] <BSlivka> Intuitive, according to user interface experts, is basically synonymous with "Habitual"
[3:11] <BSlivka> or exactly the sort of thing that you're used to
[3:12] <BSlivka> as such, intuitiveness often conflicts with efficient use
[3:12] <BSlivka> because we are used to bad interfaces
[3:13] <BSlivka> Naturally, helma becomes intuitive, as you get used to using it.
[3:14] <BSlivka> the real question is whether at that point it is logical, and efficient to use
[3:15] <BSlivka> I would say that it is more logical and efficient than a vanilla php application
[3:15] <jkridner> fair, but I'm looking for a low threshold of entry.
[3:15] <BSlivka> or even a php application framework
[3:15] <jkridner> I'm looking for a language for people who have familiarity with client-side coding only...
[3:15] <BSlivka> If you're already well familiar with javascript, it goes pretty quick, once you get the basic idea
[3:16] <jkridner> which is why I'm excited about JavaScript on the server-side.
[3:16] <BSlivka> It's of course not exactly the same as client side javacript, but you won't be fumbling over what the correct syntax is for a for loop
[3:16] <jkridner> Java-isms, such as property files, are something I'd call non-intuitive for that audience, but they are simple to pick-up.
[3:17] <BSlivka> Yeah I'm not that impressed with the property files
[3:17] <jkridner> right.? I'm looking to smooth out the new items as much as possible.
[3:17] <BSlivka> But there are frameworks you can get for helma that generate the property files automatically
[3:17] <jkridner> it is great to have efficient ways to do things for the initiated, but I want to make sure it is easy to bring people in from scratch.
[3:17] <BSlivka> And the SQL shell can generate the type.properties file from the database schema
[3:18] <BSlivka> when you say from "scratch" do you mean people that are not familiar with javascript, or not familiar with programming in general?
[3:18] <BSlivka> if not the second, then what sort of language would they be coming from? java?
[3:18] <jkridner> people only familiar with creating static web pages.
[3:19] <jkridner> coming from JavaScript.
[3:19] <jkridner> so, not really "scratch"...
[3:19] <jkridner> but, I think coding HTML+JavaScript covers a wide audience and is a fairly low barrier.
[3:19] <BSlivka> I haven't worked out the SQLShell because it has some problems with my database, but I bet it works beautifully with either of the two database systems you're using
[3:20] <jkridner> most of those people are used to cutting-and-pasting code from w3schools, etc.
[3:20] <BSlivka> oof
[3:20] <jkridner> it looks really nice with both PostgreSQL and MySQL, once I put the JDBC drivers in the classpath.
[3:21] <BSlivka> So the SQL shell makes generating the type.properties files graphical
[3:21] <BSlivka> you can do it in the browser
[3:21] <BSlivka> The main barrier with helma, I have found
[3:21] <BSlivka> is that the documentation on the helma site is not amazing
[3:22] <BSlivka> but the framework itself is, once you get it.
[3:22] <BSlivka> The macros and skins are pretty straight forward
[3:22] <jkridner> well, if there are enough users, I imagine we can get the docs cleaned up.
[3:22] <BSlivka> The main conceptual thing to get is how Helma constructs the application folder into a runtime environment
[3:23] <jkridner> I only see English versions right now.? I imagine that is an issue.
[3:23] <BSlivka> Do you have non english speakers?
[3:23] <BSlivka> where are you located?
[3:23] <jkridner> I'm actually US-based...
[3:23] <jkridner> but I'm seeking project participation world-wide.
[3:23] <BSlivka> Ah
[3:23] <jkridner> Especially China.
[3:24] <BSlivka> There should at least be documentation in german
[3:24] <BSlivka> I should expect that the german documentation is better than the english documentation
[3:24] <jkridner> India as well, but English should be good enough for most of those participants.
[3:24] <BSlivka> but I couldn't really say
[3:24] <jkridner> k
[3:24] <jkridner> how do I get to the German docs?
[3:24] <BSlivka> let me have a look
[3:27] <BSlivka> Hrmn I can't seem to find it, that's strange
[3:27] <BSlivka> I can't quite work out why an austrian framework would not have german documentation
[3:28] <BSlivka> But it seems to be the case
[3:28] <BSlivka> I won't bullshit you though. Helma has a few concepts that are probably a bit foreign to someone at home in the browser
[3:29] <BSlivka> the MVC pattern for instance
[3:29] <BSlivka> Kind of similar to so called "Unobtrusive Javascript"
[3:29] <BSlivka> but not exactly
[3:30] <jkridner> Well, the MVC pattern is part of what attracted me to Helma.
[3:30] <BSlivka> The other concept that might be difficult to wrap one's head around- is that a Helma application's URL space is not mapped to a directory structure
[3:31] <BSlivka> But instead to its object graph
[3:31] <jkridner> I had a roll-my-own JavaScript-based web server, but it was ages from being anything worth publishing.
[3:32] <jkridner> I was starting to learn Rails to get a quick MVC-based solution for my initial web development.
[3:32] <jkridner> But, I thought I'd do an evaluation of Helma before going too far down the Rails road, since it gets me closer to my long-term vision of JavaScript on both client and server sides.
[3:33] <jkridner> I'm okay with the lack of URLs mapped to the directory structure.? What gets confusing for me is that there IS dependency on the directory structure that isn't based on the URLs.
[3:34] <jkridner> Seems like they went half-way.
[3:34] <jkridner> I'd rather not depend on directory-based templates and boilerplate.
[3:34] <jkridner> I'd rather they perfect the classes and give us a clean pure JavaScript API.
[3:35] <jkridner> no problem with having templates for the skins, but don't have those based on object names.? have them specified in the API.
[3:36] <jkridner> I can add a one-liner as easy or easier than creating a directory.
[3:37] <BSlivka> The directory structure is optional actually
[3:37] <BSlivka> At least I think it is..
[3:37] <jkridner> k.
[3:38] <BSlivka> some things are optional
[3:38] <BSlivka> the main thing that the directories provide is a convenient way to organize prototype definitions
[3:38] <BSlivka> So whatever javascript is inside a folder is defined on that hopobject prototype
[3:40] <jkridner> It'd be interesting to me if I can understand the boilerplate code that is used to create the HopObjects based upon these directories (and eliminate them).
[3:40] <BSlivka> So in fact, you can skip the .macro and .hac files if you like
[3:40] <BSlivka> and define everything in a single .js file in the prototype dir
[3:41] <BSlivka> following some conventions for function naming of course
[3:41] <BSlivka> functionname_action () { } defines actions
[3:42] <jkridner> k.
[3:42] <jkridner> I guess people just got sick of doing that and wanted some more specific organization, but I'm not a fan.
[3:42] <jkridner> I like my js files to end in .js.
[3:43] <BSlivka> I myself did have a bit of a fantasy of defining an entire server side application in an object literal
[3:43] <jkridner> I guess we're yet to see how misguided we are.
[3:44] <BSlivka> If worse comes to worse, I could still do that by making a helma app that takes an object literal as input and constructs a helma app from it as a result
[3:46] <BSlivka> I think the key here is to work out how type.properties gets translated into parameters in a hopobject
[3:46] <jkridner> have you had a chance to play with users yet and authentication?
[3:46] <BSlivka> and then all you'd have to do is create new objects based on the hopobject prototype
[3:47] <BSlivka> Not much yet, I'm working up to users
[3:47] <BSlivka> the support for it seems pretty basic
[3:47] <BSlivka> I don't see anything in the way of a password security library
[3:47] <jkridner> I'm hoping to utilize OpenID.
[3:48] <BSlivka> I'm hoping for something a little bit stranger- Windows SSO
[3:48] <jkridner> I don't think that is stranger.?
[3:48] <BSlivka> Not that I'm a big fan of the technology, but that's the environment I'm working in
[3:48] <BSlivka> the trick there really I think is working out how it's done on Java
[3:49] <BSlivka> getting the java libs for it
[3:49] <BSlivka> and replicating it in helma
[3:49] <jkridner> so, yours is an enterprise deployment?
[3:49] <BSlivka> well it sort of depends on your definition of "enterprise"
[3:49] <BSlivka> It's an intranet deployment of an application for some people within a couple offices
[3:49] <jkridner> I just don't know if you can count on SSO in the "wild".
[3:50] <jkridner> yeah, that's what I meant.? inside the company.
[3:50] <BSlivka> Actually I probably won't even need to go that far
[3:51] <BSlivka> since I am doing something truly unique
[3:51] <BSlivka> maybe not unique in a good way
[3:51] <BSlivka> Have you ever heard of a system called "Sharepoint" ?
[3:52] <jkridner> yeah.
[3:52] <jkridner> ? ? ? ? ? ? ? ? ? ? ? ?
[3:53] <jkridner> met it, hated it, moved on.?
[3:53] <BSlivka> Okay so my current job is to basically help a regional office deal with an international deployment of sharepoint
[3:53] <jkridner> It has a lot of power...
[3:53] <BSlivka> as the MAIN system for the intranet
[3:53] <jkridner> but, it is too darn complicated.
[3:53] <BSlivka> I have no Administrator privilages
[3:54] <BSlivka> So there's very little I can literally do in the way of custom solutions for these guys
[3:54] <BSlivka> There's very little leeway in terms of creating custom "applications" on sharepoint, since it blocks any kind of ASP.NET codeblocks or anything fun like that
[3:55] <BSlivka> but I have found a few little gems in it that make my job possible
[3:55] <BSlivka> #1. Sharepoint does allow me to put arbitrary javascript onto a page- so I can do client side stuff
[3:56] <BSlivka> #2. Sharepoint makes available some soap services, which I can access through javascript's AJAX techniques
[3:56] <BSlivka> #3. the dataformwebpart
[3:56] <jkridner> assuming you have a URL at the same server, right?
[3:56] <BSlivka> Basically I can get limited admin privilages for specific sites within the intranet
[3:56] <BSlivka> So I can put files onto it
[3:56] <BSlivka> and shift things about
[3:56] <BSlivka> no actual server side code though
[3:57] <jkridner> k.? you can run Helma on the same machine unprivledged, right?
[3:57] <BSlivka> Nope
[3:57] <BSlivka> We've got a local web server
[3:57] <BSlivka> which I'm going to run helma on
[3:57] <jkridner> k.? so it is forwarded?
[3:57] <BSlivka> the trick here that I'm going to use is the dataform webpart
[3:57] <jkridner> k.
[3:58] <BSlivka> a webpart is basically just an encapsulated bit of functionality that can be moved around on a page
[3:58] <jkridner> ah.? Just looked it up.
[3:58] <BSlivka> it spits out two tables, and whatever code the webpart module says to spit out
[3:58] <BSlivka> the dataform webpart can take an asp.net datasource
[3:58] <BSlivka> make it available as xml
[3:58] <BSlivka> and transform it using an xslt stylesheet
[3:59] <BSlivka> it also accepts parameters which can be used in either the datasource, or the xslt
[3:59] <BSlivka> what this means is, that I can fake it.
[3:59] <BSlivka> I can write an application in helma, host it locally
[3:59] <BSlivka> and through a series of these webparts, make it look exactly like the application is running inside of sharepoint
[3:59] <jkridner> k.? but you could use any server for that, right?? no need to use Helma specifically.
[3:59] <BSlivka> that's right
[4:00] <jkridner> what drew you to Helma?
[4:00] <BSlivka> Well, I'm a bit guilty really, as I don't necessarily have the most professional of motivations for using Helma
[4:01] <BSlivka> But mostly it seems like I'll be able to get something up and running quicker using helma, than using the bog standard server technology: asp
[4:02] <jkridner> k.? Is that because of your familiarity with JavaScript?
[4:02] <jkridner> Java?
[4:02] <BSlivka> With javascript, yeah
[4:02] <BSlivka> My employment is nearly up at this company
[4:03] <BSlivka> I have other projects that are higher priority really
[4:03] <jkridner> You could write ASP stuff in JScript, right?? Not that I'd want to.
[4:03] <BSlivka> getting this helma thing done will be bonus points
[4:05] <BSlivka> Yes I could use jscript-
[4:06] <BSlivka> but I'd like to get familiar with Helma anyway
[4:06] <BSlivka> As my next job may involve heavy use of it.
[4:06] <BSlivka> Also, I was very inspired by its ability to document itself
[4:07] <BSlivka> which is kind of a step ahead of having no documentation
[4:07] <BSlivka> Helma is more heavily tested
[4:07] <BSlivka> how many heavy use websites do you know of that run on asp with jscript?
[4:08] <jkridner> I don't know any.?
[4:08] <BSlivka> And helma is actively maintained
[4:08] <BSlivka> MS don't give a flying eff about jscript
[4:09] <BSlivka> it only exists because they were trying to kill netscape
[4:09] <BSlivka> once they succeeded they pretty much forgot about it
[4:10] <BSlivka> what drew you to helma? aside from it being like rails?
[4:11] <jkridner> JavaScript on the server side was the main thing.
[4:11] <BSlivka> That's a big thing, in my view
[4:11] <jkridner> I don't know of anything else that is JavaScript + MVC on the server side.
[4:11] <BSlivka> Better code reuse is great
[4:11] <BSlivka> Well: There's trimpath junction
[4:11] <BSlivka> which was recently ported to run ontop of helma
[4:11] <jkridner> plus, using Java underneath gives a huge library of functions.
[4:12] <BSlivka> Trimpath Junction is a straight through port of Rails
[4:12] <jkridner> I'll have to take a look.
[4:12] <jkridner> do you have a reason to stay at the Helma layer, rather than going to Trimpath Junction?
[4:12] <BSlivka> It's rather interesting, because it's got code to simulate the helma server on the client side
[4:12] <BSlivka> when the client is offline
[4:13] <BSlivka> Well, for the time being, the main reason is to learn helma first
[4:13] <BSlivka> I can't imagine trimpath is going to be easy and straight forward if I don't know enough about helma
[4:13] <BSlivka> the other reason is that trimpath creates all its applications underneath its own directory
[4:13] <BSlivka> it doesn't create full fledged helma apps
[4:14] <jkridner> oh... that is REALLY interesting to me.? The offline deal is really important.
[4:14] <BSlivka> which may not be a huge drawback really, but it eliminates some of the niceties that helma provides to applications
[4:14] <BSlivka> trimpath uses google gears of course to pull off that offline trick.
[4:16] <BSlivka> The other reason is that I hate the activerecord pattern
[4:16] <BSlivka> It's an abuse of relational theory
[4:16] <BSlivka> the type.properties stuff isn't really much less of an abuse, but at least I can keep my eye on that to a certain extent, keep it in check.
[4:17] <jkridner> ah.
[4:17] <jkridner> have you ever looked at db4o?
[4:18] <BSlivka> Nope, but anything that boasts that it is an "object" database cannot be that great
[4:19] <BSlivka> I hesitate to explain much more as it begins to sound like self righteous lecturing (Unintentional).
[4:20] <jkridner> np.? i'm not a database guy.
[4:20] <BSlivka> but to summarize, Relational Model = Good; SQL = Bad; Programmers: Don't really get the relational model, or why it's good.
[4:21] <BSlivka> so you get a bunch of stuff that tries to make it easy for programmers to simply persist objects
[4:21] <BSlivka> But such systems are really ignoring most of the power and usefulness of relational databases
[4:21] <jkridner> I hate splitting problems up into multiple syntaxes/languages.
[4:21] <BSlivka> Well that's why SQL is bad
[4:21] <jkridner> right.
[4:22] <BSlivka> That's the other problem is that a lot of programmers seem to think that SQL *is* the relational model
[4:22] <BSlivka> when really it's just a bad implementation of it.
[4:22] <jkridner> that is what db4o tries to solve.? but, if it really keeps the relational model has certainly been debated.
[4:22] <BSlivka> kind of like IE6 is a bad implementation of the web.
[4:23] <BSlivka> My dream solution is relations and tuples as first class object types in javascript
[4:23] <jkridner> I get that keeping blobs of objects in a database is bad.
[4:24] <BSlivka> Only for database systems with bad implementations
[4:24] <BSlivka> It really depends on the situation
[4:25] <BSlivka> The main power of the relational model is that it's more than just a dumb data store
[4:25] <BSlivka> you can use it to reason about your data
[4:26] <BSlivka> in a properly normalized database, the data obtains a kind of meaning
[4:26] <jkridner> are you a fan of XML queries?
[4:27] <BSlivka> eh, not really
[4:27] <jkridner> k.? that's good.
[4:27] <BSlivka> xpath is really unweildy, and as for xquery- an XML document is not a relational database
[4:28] <jkridner> I'll let you know that the site I'm trying to create should be strewn with RDFa.
[4:28] <earl left the chat room. (Remote closed the connection)
[4:29] <BSlivka> Okay. I haven't learned enough about RDF to really say authoritatively whether it's a good idea or not.
[4:29] <BSlivka> well... authoritatively to myself- I don't hold a lot of authority over others!
[4:29] <BSlivka> I tried reading some of the specs and never really got it
[4:30] <BSlivka> The basic idea seems to be about making a sort of database interchange format
[4:30] <BSlivka> I'm a bit wary of the wisdom of querying RDF files directly though
[4:31] <BSlivka> as SPARQL seems to be attempting
[4:31] <jkridner> RDF gets interesting when you couple it with DCMI.
[4:31] <jkridner> RDF is just a language for describing triples.
[4:32] <BSlivka> DCMI, so that's like a standardised semantics body yes?
[4:32] <jkridner> yeah.
[4:32] <BSlivka> Hrmn
[4:33] <jkridner> RDFa, however, gets you out of the XML and into an actual web page.
[4:33] <jkridner> the Junction "Don't Repeat Yourself" mantra seems to apply.
[4:34] <BSlivka> Ahh yeah, I've seen some of that
[4:34] <BSlivka> Ah, DRY is from rails itself!
[4:34] <BSlivka> and from there probably from somewhere else
[4:34] <BSlivka> but anyway, besides the point
[4:34] <jkridner> RDFa lets you specify semantic information without repeating it in an XML file.
[4:34] <BSlivka> I've seen a webpage or two with a bunch of DC properties in the header
[4:35] <BSlivka> Are you familiar with microformats?
[4:35] <jkridner> indeed.
[4:35] <jkridner> I believe RDFa is the W3C attempt to reclaim what the Microformat guys are doing.
[4:36] <jkridner> I'm a huge fan of microformats, but I think RDFa gives a bit more roadmap.
[4:36] <BSlivka> Microformats get a lot of criticism, but I think they're an important stepping stone between plain jane HTML and full on RDF
[4:36] <BSlivka> because you don't have to grasp a lot of theory and technical information in order to just use microformats
[4:37] <BSlivka> wheras there's no easy way to get into RDF
[4:37] <jkridner> I think RDFa does a fair job at completing that gap.
[4:37] <jkridner> RDF destroys the whole DRY principle.
[4:37] <jkridner> RDFa brings it back.
[4:37] <BSlivka> I would say that GRDDL is probably a better step between microformats and full RDF
[4:38] <jkridner> so, can I install Trimpath on top of Helma?
[4:38] <BSlivka> Yeah I believe so
[4:38] <BSlivka> I haven't actually tried trimpath
[4:38] <BSlivka> so I can't vouch for its quality
[4:38] <BSlivka> I've only read the hype
[4:40] <jkridner> ? ? ? http://www.xml.com/pub/a/2006/04/26/microformats-grddl-rdfa-nvdl.html?page=3 ? ?
[4:41] <jkridner> "While you can think of? GRDDL as a bridge from microformats to RDF, you can think of RDF/A as microformats? done the RDF way in the first place."
[4:42] <jkridner> adds some namespace complexity.
[4:42] <BSlivka> Sure
[4:42] <jkridner> I think that is mostly a good thing, since we should have our formats defined with namespaces.
[4:43] <BSlivka> I'm sure it's very nice- in my mind the barrier is not who has the superior technology though.
[4:43] <BSlivka> It's the strategy for adoption
[4:43] <jkridner> certainly.
[4:43] <BSlivka> And in that case, there is a stark difference between MF's and the w3c
[4:44] <jkridner> yeah, but there is little reason not to add RDFa parsers in places where you'd have MF parsers.
[4:44] <BSlivka> basically, the w3c is saying "Here's a bunch of technology that's based on theory X Y and Z, so therefore it should work for just about any problem you can possibly think of"
[4:45] <BSlivka> while Microformats are saying "Here's a technology that solve this specific problem that you have"
[4:45] <jkridner> absolutely.
[4:46] <jkridner> when you can arrive at a generic solution that works well for solving specific problems, then you have a real winner.
[4:46] <BSlivka> In order for RDF to be successful in the mainstream, they need to have a message more along those lines
[4:46] <BSlivka> Whereas at the moment, they only seem to be sending that message to larger organizations
[4:46] <BSlivka> and largely ignoring the general internet population
[4:46] <jkridner> Operator now supports RDFa.
[4:47] <BSlivka> Of course the MF message isn't really that great either, because while it's somewhat more accessible than RDF
[4:47] <BSlivka> it's still completely opaque to the general browsing public
[4:48] <BSlivka> At least until firefox3
[4:48] <BSlivka> and even then, it's only going to be a fraction of web users that are using ff3
[4:49] <BSlivka> Ah here's another problem with RDFa, it's based on xhtml
[4:50] <BSlivka> one of the huge advantages of microformats is they work even in tag soup
[4:51] <BSlivka> RDFa seems to depend on a working namespaces implementation, which pretty much locks out most of the browsing public until IE gets its act together
[4:52] <BSlivka> Not that i'm trying to poke holes in it or anything :()
[4:52] <BSlivka> back to work!

 

 

In the channel now:

Logs by date: