DRhttp://harborwebs.com:8080/Net379/v0.0.5.NET379.XML

I checked it out a while ago, and now I've taken another look. :-)

Here are some quick points (in no particular order):

 

This format requires secondary parsing (to split the string into separate
flags), which in my opintion we should try to avoid, since we can use the
XML parser for that instead.


 

The various connection methods/protocols are pretty likely to change over
time so placing them in the tag name seems like a bad idea. Sure, it's
possible to update the DTD:s or Schema to add/remove valid elements but
that makes the procedure more complex than it needs to be.

I also think it would be good to encapsulate the different connection
methods (PSTN, ISDN, TCP/IP) somehow, so that flags and other data could be
specified for a particular service (and the DTD/Schema can be used to
enforce valid elements). Structure and the ability for multiple levels of
data is one of the primary advantages of XML so we should try to use it.
:-)

How about something like this:











 
 
 
 








... some kind of info on when this service is available
(CM, Txy...) ...






Here "pstn", "isdn", "inet" and
"transx" are different "transports", which need
different sets of info to be used. E.g. internet transports don't have
phone numbers, and modem transports don't have IP info. This needs a lot of
thinking. Anyone have any good ideas?




*I* like the idea of putting number & status as attributes of the
elements, but Håkan Karlsson (who's writing a high performance XML-SLF
converter for DOS) argued that it's much simpler for him if all data is
stored as child elements, instead of using both attributes and children. We
shouldn't let technical limitations dictate the standard but it doesn't
hurt to keep them in mind. Maybe it would be simpler for everyone if all
vital data is stored in child elements and attributes only used for meta
data? I don't know...

  Jesper,
  yeppe{at}enjoy.cc
---