[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [JDEV] First cut at a DTD



> Particular issues:
> Is "nick" required for a login packet, or optional?

Optional, actually, they are all optional, you can send a login with just
a nick and it will create an anonymous session if the server config allows
it.

> Which, if any, fields in a message packet are required?  Right now,
> this shows only "to" and "say" as required.

To is required, but there's nothing stopping a client from sending a
message with just a to and an ext, so say wouldn't really be required
either...

> Notice how many elements have #PCDATA for content and no attributes.  
> This usually indicates that the DTD cannot capture complete knowledge
> about the data.  (Typically resulting in extra work for the XML
> application.)  For instance, my instinct tells me that there are only
> certain allowed values for "icon" tags.  This might better be captured
> as
> 
> <!ENTITY %iconTypes "(online|away|happy|sad|hungry)">
> <!ELEMENT icon EMPTY>
> <!ATTLIST icon
>   type  %iconTypes  #REQUIRED
> >

I'd like to leave icons open to user definition, but have a base set of
standard ones.  So that in the future you might be able to do an <icon
href="http://asdf/suprise.gif">golly gee</icon> and have a custom icon
appear in clients that support it, would be great for transports that want
to supply the custom icons from their heritage(ICQ for instance).

> This would require the icon type to be one of those in the list.  
> (Priorities might be another good example of this.)

Priority will always be an integer, it's what the server uses to guage
which connected session for a user will be the default recipient for
incoming messages. (highest wins)

> Is a "say" required for a status packet?  (Currently shows as required.)

Probably not, so that a client could connect and set their priority to the
highest so that it's the default, but not alert anyone to their presence.

> Can a roster packet include multiple "get" elements?  Can they be
> mixed with multiple "del" and "add" elements?

Sure, why not :)  It all gets processed the same way on the server.

> jabber.dtd
> ----------Cut here-----------
> <?xml version="1.0" encoding="UTF-8"?>
> ......

Looks very nice!  Thanks, I've been wanting something like that for some
time but I just can't figure out the strange syntax and can't find the
spec defining it(EBNF or something ;-)

As far as I understand it though, with reguard to XML and DTDs, they are
really most useful in special applications requiring "pure" strict data
and in XML editors providing the user rules when composing a document,
right?

With how the server is designed, they wouldn't work at all by defualt,
since the server is as future-proof as I can make it.  It allows
_anything_ for the XML, and only extracts what it needs from the parsed
XML, ignoring the rest.  This way the protocol can grow and adapt and not
disturb the old servers installed, they might just miss out on a few newer
features. Adding a strict DTD check into the server would pretty much put
an end to that, but it might be very useful for a client.  Actually, it
might be an excellent option for testing minimal adherence to the spec
from clients and servers, or as a debugging option on the server for the
paranoid :)

I really do like having the DTD though, it provides a clear and automated
understanding of the protocol, it's the definition of the protocol.

Thanks!

Jer