DR>> Which brings up a point, should we go DTD or schema? I think schema
 DR>> but I am no expert in these matters.

 JS> Me neither. Schema is more advanced so I think that's what we need to
 JS> use. For one thing it allows us to lock down the _type_ of the data
 JS> fields (integer, string, date) and even valid formats (specified by a
 JS> regexp of some sort if I'm not mistaken). But I think we can worry
 JS> about that later... :-)

Sure we can worry about it latter. But we should be thinking about it. At
least keep it in the back of our minds.

 JSpstn>
 JSnumber/number>
 JSflagflag>
 JSflagflag>
 JSspeed/speed>
 JS/pstn>

 DR>> hmm... so you prefer children to attributes?

 JS> I dunno... Decisions decisions... :-)

Yep...

 JS> We can probably worry about that later too, when we know more about
 JS> what we want to stuff in there...

true and yet more decisions...

 DR>> For the flags, wouldn't
 DR>> it be best to go a step further with the type of flag? At least for
 DR>> the known types and then have a generic flag type?

 DRflagSpeed/flagSpeed>
 DRflagOnline/flagOnline>
 DRflagModem/flagModem>
 DRflagUpdate/flagUpdate>
 DRflagCompression/flagCompression>

 JS> You're right. But that makes "flag" a bit redundant so make those
 JS> "speed", "online" etc. instead.

Sure... I like that better

 JS> BTW, by "modem" you mean modem protocols right? Like V34
and V90? How
 JS> about "protocol" instead?

good idea!

 JS> Yes of course. I was just making some examples :)

 DR>> I think that Transx should also fall under INET.

 JS> Yes, technically it would, but I was thinking along the lines of how
 JS> one actually use them. Binkp, Telnet, VMP & Ifcico are direct
 JS> "protocols" running over TCP. Transx is an other
"type", since it
 JS> doesn't use connections but simply emails the packet to an email
 JS> address... You don't use IP addresses with Transx. Make any sence?

Does it make any sense? Maybe. I could get picky about your "definition" of
what IP. The user sending that pkt via email has to use IP to send it. :-)

 DR>> I think we should look at it this way. If an element can possibly have
 DR>> an attribute then it should be a child. If it cannot have an
 DR>> attribute, then /IT/ should be an attribute. If it makes it easier for
 DR>> parsing then perhaps everything could be a child.

 JS> Let's keep it open for now. :-)

I am open to doing that. But it would help us to define a structure if we
knew exactly what should be an attribute and what should be a child.

With best regards, Dale Ross.  E-mail: Dale.Ross{at}p1.f1.n379.z1.fidonet.org

--- Fidolook Lite FTN stub