But first, you should get (and I really mean get, because you will re-read it again and again) “How To Talk So Kids Will Listen and How To Listen So Kids Will Talk”, which is also by Adele Faber and Elaine Mazlish. (Actually, get two copies because you’ll need one to lend to the other adults in your children’s lives.) “How To Talk…” provides the basic parenting skills that “Siblings Without Rivalry” then builds on.
Having avoided RDF like the veritable plague for years, I have been forced to look at it properly for my latest “put RDFa on our web pages” project. So the other day I came across this weirdness surrounding “QNames” in Turtle, SPARQL and RDFa (and so on)…
As we all know, RDF is about making statements about resources, and resources are identified by URI. And the predicates/properties that you use to make statements about resources are also identified by URI. So I can say things like (in Turtle syntax):
<http://www.lmnl.org/wiki/Creole> <http://purl.org/dc/elements/1.1/creator> [<http://xmlns.com/foaf/0.1/weblog> <http://www.jenitennison.com/blog>] .
Another fascinating post from Bill de hÓra, this time on URL design for resources:
Let’s take editing some resource, like a document, and let’s look at browsers and HTML forms in particular, which don’t a do a good job of allowing you to cleanly affect resource state. What you would like to do in this suboptimal environment is provide an “edit-uri” of some kind. There are basically 5 options for this; here they are going from most to least desirable
- Uniform method. Alter the state by sending a PUT to the document’s URL. The edit-uri is the resource URL. URL format: http://example.org/document/xyz
- Function passing. Allow the document resource to accept a function as an argument. URL format: http://example.org/document/xyz?f=edit
- Surrogate. Create another resource that will accept edits on behalf of the document. URL format: http://example.org/document/xyz/edit
- CGI/RPC explicit: send a POST to an “edit-document” script passing the id of the document as a argument. URL format: http://example.org/edit-document?id=xyz
- CGI/RPC stateful: send a POST to an “edit-document” script and fetch the id of the document from server state, or a cookie. URL format: http://example.org/edit-document
- you get to meet people from all corners of the XML community, even ones you haven’t got the slightest interest in, and learn that they’re human too (even the web services guys)
- there’s always something to learn; I’ve seen some talks for six years on the trot, others were completely new this year, but they’re all worth attending because the audience, war stories and discussion are always different. Also, because each talk is aimed at newcomers, you get a great overview of topics that you’re not so familiar with, and you can always chat to the speaker later to find out more
- there are social events laid on every evening that you’re expected to attend, so you’re practically forced to socialise, which is useful for an insecure introvert like me who’d otherwise be sitting in her hotel room getting miserable imagining everyone else having a good time
- there’s a creche, so despite being inseparable from two small children over the last four years, I’ve still been able to attend without dragging an entourage with me (not that I object to the entourage, just the expense and the dependency)
I left feeling not only invigorated and inspired, but also a part of a fun and friendly community.
I don’t know anything about Struts 1, but Bill de hÓra’s recent post has got some interesting web-application-design tips. There were two particular bits that spoke to me:
struts-config.xml struts-config tries to capture primarily the flow of application state on the server, by being an awkward representation of a call graph. In doing it misses a key aspect of the web - hypertext. In web architecture, HTML hypertext on the client is the engine of application state, not an XML file on the server.
In other words (I think) in web applications your state in the page you’re on and taking action is about following the links (or submitting the forms) on the page. Your actions (and therefore the transitions between different states) are determined by what links and forms are on the page. But in fact, URLs should be hackable, and transitions unlimited. When you design the application what you really need to think about are the tasks the users want to achieve (and therefore the transitions that they might want to make) rather than the possible state transitions.