[...]Some XML-like simplified markup language will suffer the
classic chicken and egg problem (if there were tools and applications, people
would be interested; without people being interested, nobody will develop
tools and applications). [...]
Hi Michael. Glad to see you're still hanging around. I think the people on this list, hanging around like you, comprise the interested group we need. Any new technology would have to spread by the word of mouth through these people, through contagious excitement. If we can get this group to solidify on something and to be excited about that something, I think we stand a chance.
>[...] it would be interesting to see your proposal![...]
I fear it won't be so interesting. I've thought some more about what it is we'd need to accomplish and decided that I really don't know, so I have no clue whether this proposal does the trick.
If we decide that we need a good serialization language, well, then we would probably end up with something close to YAML. If we decide we need a good way to mark up human verbage, well, then we would probably end up with something like Paul's PXML. If we decided that we need a language that does a little something for everybody, well, then we would probably end up with XML.
I think our success hinges critically on us picking a problem or a set of problems to solve and then finding a darn good solution.
But I'll give you the proposal anyway. The proposal is to tweak MinML to fix a few things that bug me. It therefore solves the problem of Joe Lapp feeling bugged.
I wrote an information model and a BNF, but I won't bother you with them. Here are the most significant tweaks to MinML:
(1) Element names are modelled on domain/host names. There is no separate mechanism for namespaces. My syntax lists the most specific component name first, as in "date.someplace.com", so that the most meaningful name occurs first and is easiest to spot.
(2) I provide a mechanism for abbreviating namespaces. I think this little example will convey the whole idea:
<.domain>product.tailsforhumans.com</>
<.alias>$prod = product.tailsforhumans.com</>
<_>The following two elements have the same name</>
<description.$prod>Bona fide pig's tail</>
<description.product.tailsforhumans.com>Bona fide cat's tail</>
I was allowing aliases to appear only at the end up a name, and I wasn't allowing aliases to be defined in terms of other aliases. But I was allowing this:
<.alias>$desc = description.product.tailsforhumans.com</>
<$desc>Bona fide Tim B-L tail</>
(3) As you just saw, the end tag need not contain the element name, but I do make it optional.
(4) There is no requirement that a single root element contain everything.
(5) There are no XML character references. Only the '>' needs to be escaped, and it is escaped as '>>'. We could always support C-like character references such as '\n' and '\xA'.
(6) The information model guarantees that "<x></>" always means null and not empty string.
That's basically it. I don't know what to make of character encodings. That seems like such a mess too. I want a language that people who aren't experts in character encodings can implement from scratch.
I think we should start up a conversation about what the problems are that we care to solve. For example, the above proposal probably isn't very good for marking up human verbage since it doesn't support anything like mixed content. Is it legitimate for us to identify the problems according to what ails us about XML?
Hey, glad to be back in the fray again. Thanks for the welcome back!
~Joe
Send Email