In this post, I'm going to be reviewing my old posts with what I've learned over the past few years. The purpose behind this analysis is to consolidate my ideas into fewer ideas and hopefully come up with some new insights along the way.
This was my first post about XML entity references. The goal was to restrict the DTD grammar to only entities so facilitate usage in other applications that have no concern about elements and attribute lists. Now I would recommend using only DTD since its usage is widespread. I was considering folding this into a macro system I was planning to write, so that one could replace © with © just as easily as it could replace sqrt(4) with 2. I've come to the conclusion that this post was premature, and needs to be included in a more detailed discussion about macro systems, and templating systems such as M4, Genshi, Mustache, and many others.
This was an example of binary parsing, which is still not possible in many languages, but a topic more suited to C structs. GCC has a large number of attributes and packing parameters that accomplish some of the goals of binary parsing, but I still haven't found a good binary parsing framework to date.
This was a bunch of things trying to make Go something that it wasn't. I have since found the Rust programming language, which has all the features I was looking for in this post and more. So, now I would recommend using Rust.
The following posts were all about RDF:
This was a comment primarily intended to allow for arbitrary Common Lisp lists to be represented in RDF.
This was a comment as well, and I still haven't found a datatype URI for this, perhaps something for a future article.
This is interesting because there isn't an XSD datatype associated with large finite-size integers, although you could define it as xsd:integer, then restrict the domain until it matches int128_t. I have since defined a URI for this on my other website.
This is a type of post I'd like to write more of. You know, explaining the pros and cons of certain implementation techniques and why one is better or worse than the other.
This was attempting to illustrate the inconsistencies that I found between different XML standards.
- Type = rdfs:Class
- ObjectType = owl:Class
- DataType = rdfs:Datatype
- Property = rdf:Property
- ObjectProperty = owl:ObjectProperty
- DataProperty = owl:DataProperty
The following posts were unintentionally about Data URIs:
This was attempting to solve a problem that Data URIs already solve. Now I recommend using Data URIs instead.
This was a good comment, but I don't recommend these namespaces anymore. Now I recommend using Data URIs instead, for example:
This mentions a problem regarding xsd:hexBinary and xsd:base64Binary, which can be solved in several ways:
- Candle assigned the type identifier "binary" to the combined value space.
- The MediaType "application/octet-stream" is naturally isomorphic to the binary datatype.
- The Data URI <data:application/octet-stream,DATA> may be used to represent data of type binary.
- The URI
<http://www.iana.org/assignments/media-types/application/octet-stream>may also be used to represent the binary datatype itself.