DR>> http://harborwebs.com:8080/Net379/v0.0.5.NET379.XML

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

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

 JS> CM,V32b,V42b,XA

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

I agree with you. I am in the middle of writing a message for a 
proposal. For the flags above I was thinking it should be something like
this


 
 


 JS> 

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

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

I was thinking something along these lines:


  


But then the more I think about it, ITN, IFC, IBN, ITX should all be
children instead of attributes, because they require attributes! Unless we
decide to put IP protocol attributes in DNS records...

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

I do not disagree. I made some changes based on feedback from Scott Little.
Those included removing HUB and moving Net out from under Regions. Scott
suggested that the deeper we took things in the structure, the more
complicated it would be to parse.

 JS> How about something like this:

 JS> 
 JS> 1-555-999-9999
 JS> V32b
 JS> V42b
 JS> 33.6
 JS> 

hmm... so you prefer children to attributes? For the flags, wouldn't it be
best to go a step further with the type of flag? At least for the known
types and then have a generic flag type?







 JS> 
 JS> 1-555-999-9999
 JS> X75
 JS> V110L
 JS> V110H
 JS> V120L
 JS> V120H
 JS> 64
 JS> 

Ah yes, I forgot about ISDN in my proposal. Again, shouldn't the various
flags be defined by name a little more?

 JS> 
 JS> foo.bar.com
 JS> 24554
 JS> BinkP
 JS> 512
 JS> ... some kind of info on when this service is available (CM,
 JS> Txy...) ... 

 JS> 
 JS> user{at}foo.bar.com
 JS> 

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

Yes, I think you are leaving out transport methods. For Inet you are using
ONLY BinkP while there is also TELNET, IFCIO, VMODEM, FTP etc. I think that
Transx should also fall under INET.

 JS> 

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

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

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

--- Fidolook Lite FTN stub