Crossposting: XHTML/XML and Tiddlywiki
31 views
Skip to first unread message
Jonnan
Nov 13, 2009, 3:30:30 PM11/13/09
to TiddlyWikiDev
I'm not. frankly, smart/skilled enough to qualify my thoughts
regarding moving Tiddlywiki to pure xhtml as a matter of 'flaws'. I
can't think of a single thing that xml based tiddly-wiki could do that
couldn't be done as it is written - Even my simple svg interpreter
*works* for embedding SVG into a tiddler - not perfectly, but with
moderate effort you can create icons, chapter headings, et all.
That said - One of the things I really like about Tiddlywiki is the
pure text aspect. I'm not religious about it, but I liked it in Unix,
I liked it learning html, and I like it in Tiddlywiki. It lets you
take it apart and tinker with things, and every bit of javascript that
stands between me and dealing with the raw svg (or other markup)
helps highlight the fact that I don't *really* know what I'm doing
(particularly when dealing with *just* enough changes that I don't
realize why a script that would work in a regular document won't work
quite right as a plugin).
Which is fine - I'm used to it. But, it seems to me that Tiddlywiki
would not lose anything by transitioning from html (with internal xml)
to a completely xhtml base, in which you would *not* (To my simplistic
point of view) need to work around the minor differences between the
'almost' XML of html and the 'actual' XML of XHTML.
But would gain considerable simplicity in embedding XML inside
Tiddlywiki. Something as simple as a systemXML tiddler could contain
the dtd link in the same fashion as a systemServer tiddler does now,
and you have access to any XML you want.
The fact that I haven't seen anyone else that thinks this *probably*
means I'm fundamentally misunderstanding the situation - I am after
all asking for a major change in the entire underlying concept,
basically for my personal convenience, and the fact that plugins would
have to be redesigned to be XML compatible is a legitimate objection.
But if I'm not fundamentally making a stupid suggestion, it might make
many things simpler in the long run.
Jonnan
(Apologies, it was implied I mis-posted this in the user-group -
Context Follows)
>> I'm just curious. It seems to me that converting tiddlywiki to a pure
>> xhtml (rather than the mixed html+internal xml base it has now) would
>> open up some option regarding xml data being inserted into the
>> tiddlers, which in turn would open up a plethora of specialized data
>> like svg, mathml, virtually any xml with a schema should be embeddable
>> in a tiddler fairly easily (As opposed to embedding it with
>> workarounds as is done now). And I'm not seeing any options html opens
>> that xhtml really closes off.
>> Yet - This forum is chock-full of people smarter than me, and
>> searching the forum shows a marked lack of interest in such a
>> transition. Which probably means I'm not nearly as clever as I think I
>> am, and will look really stupid asking why this would be a bad thing.
>> Turns out I don't mind looking really stupid and asking - why the lack
>> of interest in transitioning this to a pure xhtml base? I'm obviously
>> missing something.
>> Thanks - Jonnan
-----
>> I'm just curious. It seems to me that converting tiddlywiki to a pure
>> xhtml (rather than the mixed html+internal xml base it has now) would
>> open up some option regarding xml data being inserted
> Can you elaborate on the flaws you've encountered - preferably over at
> http://groups.google.com/group/TiddlyWikiDev/
> -- F.
----
regarding moving Tiddlywiki to pure xhtml as a matter of 'flaws'. I
can't think of a single thing that xml based tiddly-wiki could do that
couldn't be done as it is written - Even my simple svg interpreter
*works* for embedding SVG into a tiddler - not perfectly, but with
moderate effort you can create icons, chapter headings, et all.
That said - One of the things I really like about Tiddlywiki is the
pure text aspect. I'm not religious about it, but I liked it in Unix,
I liked it learning html, and I like it in Tiddlywiki. It lets you
take it apart and tinker with things, and every bit of javascript that
stands between me and dealing with the raw svg (or other markup)
helps highlight the fact that I don't *really* know what I'm doing
(particularly when dealing with *just* enough changes that I don't
realize why a script that would work in a regular document won't work
quite right as a plugin).
Which is fine - I'm used to it. But, it seems to me that Tiddlywiki
would not lose anything by transitioning from html (with internal xml)
to a completely xhtml base, in which you would *not* (To my simplistic
point of view) need to work around the minor differences between the
'almost' XML of html and the 'actual' XML of XHTML.
But would gain considerable simplicity in embedding XML inside
Tiddlywiki. Something as simple as a systemXML tiddler could contain
the dtd link in the same fashion as a systemServer tiddler does now,
and you have access to any XML you want.
The fact that I haven't seen anyone else that thinks this *probably*
means I'm fundamentally misunderstanding the situation - I am after
all asking for a major change in the entire underlying concept,
basically for my personal convenience, and the fact that plugins would
have to be redesigned to be XML compatible is a legitimate objection.
But if I'm not fundamentally making a stupid suggestion, it might make
many things simpler in the long run.
Jonnan
(Apologies, it was implied I mis-posted this in the user-group -
Context Follows)
>> I'm just curious. It seems to me that converting tiddlywiki to a pure
>> xhtml (rather than the mixed html+internal xml base it has now) would
>> open up some option regarding xml data being inserted into the
>> tiddlers, which in turn would open up a plethora of specialized data
>> like svg, mathml, virtually any xml with a schema should be embeddable
>> in a tiddler fairly easily (As opposed to embedding it with
>> workarounds as is done now). And I'm not seeing any options html opens
>> that xhtml really closes off.
>> Yet - This forum is chock-full of people smarter than me, and
>> searching the forum shows a marked lack of interest in such a
>> transition. Which probably means I'm not nearly as clever as I think I
>> am, and will look really stupid asking why this would be a bad thing.
>> Turns out I don't mind looking really stupid and asking - why the lack
>> of interest in transitioning this to a pure xhtml base? I'm obviously
>> missing something.
>> Thanks - Jonnan
-----
>> I'm just curious. It seems to me that converting tiddlywiki to a pure
>> xhtml (rather than the mixed html+internal xml base it has now) would
>> open up some option regarding xml data being inserted
> Can you elaborate on the flaws you've encountered - preferably over at
> http://groups.google.com/group/TiddlyWikiDev/
> -- F.
----
Paul Downey
Nov 14, 2009, 6:36:50 AM11/14/09
to tiddly...@googlegroups.com
Hi Jonathan
> It seems to me that Tiddlywiki
> would not lose anything by transitioning from html (with internal xml)
> to a completely xhtml base, in which you would *not* (To my simplistic
> point of view) need to work around the minor differences between the
> 'almost' XML of html and the 'actual' XML of XHTML.
I'm not sure what you're saying here. TiddlyWiki cooks as
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
and is well-formed XML, passing through xmllint, etc.
I don't think we /lose/ anything from being strict XML rather than HTML,
but the question is what do we gain?
Parsing XML in JavaScript cross-browser, especially with
namespaces, is actually harder than parsing HTML and JSON.
And then there is the duality of browsers which present XHTML as
a HTML DOM and some other browsers which treat strict XHTML
served with the correct media-type as XML, displaying angle brackets
instead of text.
Generating and parsing TiddlyWikis in XSLT is trivial and if for
some reason it's HTML rather than XHTML, then you can use tidy
or TagSoup in the pipeline, HTML-parser in Perl, HTML5 parser in
Python, etc. These all work just fine until they encounter wikitext
and macros.
So a better tactic for processing TiddlyWiki content is usually to
use TiddlyWiki itself to save the tiddlers in an alternative format,
such as RSS and process that.
If you use TiddlyWeb, then there is a framework for mapping
tiddlers to and from a variety of other formats.
Strategically XML is alive, but XHTML for Web pages is a bit of
a dead end, especially in the face of HTML 5.
Make sense, or have I completely missed the point?
--
Paul (psd)
http://blog.whatfettle.com
Tobias Beer
Nov 14, 2009, 6:45:39 AM11/14/09
to TiddlyWikiDev
Hi Jonnan,
What's are your main ideas, drives, intentions or incentives as for
"moving completely to" xhtml?
1) To allow for better parsing by 'external' apps?
2) To be more strict on the use of attributes, structure, naming?
3) To switch to possibly more future-proof name-space conventions?
4) To be prepared for the ubiquiteous dawn of svg?
5) To possibly improve embedability, portability and os-independence
even further?
6) Do you just have that gut feeling that it might be a drawback not
to make the move (any time soon)?
Just in general, I find XML to be an utterly awful construct and I
wish some sort of js/json dialect would be the slick kind of structure
defining all web-elements, instead of this sort of bloated,
exhaustively redundant, hardly readable format ...and I don't mean to
just rant away on it. It's good to have reliable standards and XML
surely has evolved into that for many people, just like good 'ol java
did ...just can't do without main(). I'ts just that, in some respects,
XML feels like a straitjacket which you'd rather want to take off,
asap.
By the way... is there any svg playground of yours to be played with
out there?
Tobias.
What's are your main ideas, drives, intentions or incentives as for
"moving completely to" xhtml?
1) To allow for better parsing by 'external' apps?
2) To be more strict on the use of attributes, structure, naming?
3) To switch to possibly more future-proof name-space conventions?
4) To be prepared for the ubiquiteous dawn of svg?
5) To possibly improve embedability, portability and os-independence
even further?
6) Do you just have that gut feeling that it might be a drawback not
to make the move (any time soon)?
Just in general, I find XML to be an utterly awful construct and I
wish some sort of js/json dialect would be the slick kind of structure
defining all web-elements, instead of this sort of bloated,
exhaustively redundant, hardly readable format ...and I don't mean to
just rant away on it. It's good to have reliable standards and XML
surely has evolved into that for many people, just like good 'ol java
did ...just can't do without main(). I'ts just that, in some respects,
XML feels like a straitjacket which you'd rather want to take off,
asap.
By the way... is there any svg playground of yours to be played with
out there?
Tobias.
Jonnan
Nov 20, 2009, 11:28:59 AM11/20/09
to TiddlyWikiDev
My apologies - Busy Week.
Personally, as a layman that has a hard time even getting into thing
like the DOM in Firefox, I find
A) Playing with XML structures is an incredibly useful way of
organizing information. I can use the structure to setup a consistent
way of accessing the information, I can depend on the way other
software interprets it to be consistent, and if I need to figure
something out it's easy to tweak till it's the way I want it.
B) Numerous others have evidently had the same reaction - MathML and
SVG are the two most obvious results to me, but when I look at the
Wikipedia Listing I see a dozen others in common use, and others that
pique my interest (Just looking I sit and go "Cool, there's a
MusicML!". I have know idea how to use it, but I could put Bach in TW!
Coool!)
C) As mentioned, one of the things that I imprinted on when younger is
the text based protocol of Unix. I learned HTML by taking the Lynx
browser bookmark file apart. I tore scripts apart to learn sed, perl -
maybe not well, but enthusiastically.
Obviously, TiddlyWiki works well for me. But then you get into a few
things, like XML (and yes, SVG in particular. Because I think SVG is
frickin' cool. It's a graphical system that I can tweak by looking at
a text file. See 'C)' Above - <G>) that seem like they *should* port
over into Tiddlywiki, but don't port well, or port incompletely, and
there's no immediately obvious reason why that should be the case. To
me, it looks like it ought to be a match made in heaven - embedding
text-based markup language in TW is a nobrainer.
This may in fact imply I have No Brains because there is something
breathtakingly obvious that TW would lose by setting up a general
system that allowed *any* XML to be embeddable in the wiki in a
consistent manner rather than using one-off scripts designed for
specific languages. Darned if I see it though.
On the other, an SVG playground -
http://www.openclipart.org/ has about 12,000 SVG items in it. Another
obvious place is Wikipedia, which often prefers SVG in it's
illustrations.
Inkscape is the best SVG editor I've seen outside a text editor,
although it has some design decisions I disagree with.
http://xmlgraphics.apache.org/batik/ is a good SVG interpreter, I tend
to use it when something I'm trying to do doesn't work in Firefox, and
I'm trying to determine if it *should* but does not, or if I've simply
misunderstood something.
Jonnan
Personally, as a layman that has a hard time even getting into thing
like the DOM in Firefox, I find
A) Playing with XML structures is an incredibly useful way of
organizing information. I can use the structure to setup a consistent
way of accessing the information, I can depend on the way other
software interprets it to be consistent, and if I need to figure
something out it's easy to tweak till it's the way I want it.
B) Numerous others have evidently had the same reaction - MathML and
SVG are the two most obvious results to me, but when I look at the
Wikipedia Listing I see a dozen others in common use, and others that
pique my interest (Just looking I sit and go "Cool, there's a
MusicML!". I have know idea how to use it, but I could put Bach in TW!
Coool!)
C) As mentioned, one of the things that I imprinted on when younger is
the text based protocol of Unix. I learned HTML by taking the Lynx
browser bookmark file apart. I tore scripts apart to learn sed, perl -
maybe not well, but enthusiastically.
Obviously, TiddlyWiki works well for me. But then you get into a few
things, like XML (and yes, SVG in particular. Because I think SVG is
frickin' cool. It's a graphical system that I can tweak by looking at
a text file. See 'C)' Above - <G>) that seem like they *should* port
over into Tiddlywiki, but don't port well, or port incompletely, and
there's no immediately obvious reason why that should be the case. To
me, it looks like it ought to be a match made in heaven - embedding
text-based markup language in TW is a nobrainer.
This may in fact imply I have No Brains because there is something
breathtakingly obvious that TW would lose by setting up a general
system that allowed *any* XML to be embeddable in the wiki in a
consistent manner rather than using one-off scripts designed for
specific languages. Darned if I see it though.
On the other, an SVG playground -
http://www.openclipart.org/ has about 12,000 SVG items in it. Another
obvious place is Wikipedia, which often prefers SVG in it's
illustrations.
Inkscape is the best SVG editor I've seen outside a text editor,
although it has some design decisions I disagree with.
http://xmlgraphics.apache.org/batik/ is a good SVG interpreter, I tend
to use it when something I'm trying to do doesn't work in Firefox, and
I'm trying to determine if it *should* but does not, or if I've simply
misunderstood something.
Jonnan
Reply all
Reply to author
Forward
0 new messages