ptsn phone="">
 flags speed=""
 >>            online=""
 >>            modem=""
 >>            update=""
 >>            compression="">
 /flags>
 /ptsn>

 CC> Since speed and compression are potentially fields we would want to
 CC> limit to the validation of only a "given" set of values,
these should
 CCflags>.

OK I will change that.

 CC> Not sure what modem, online, & update reflect though.

Those are the flag fields in the current SLF nodelist.

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

 CC> XML Schema, most definately!

From what I understand this is the best way to go. We will need some experts
to help us develop a good schema (nudge, nudge)

 >> 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...

 CC>   What attributes do they require?  port number?  hostname?  ip
 CC> address?

Yes, yes and yes

 >> 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
 flagSpeed/flagSpeed>



 CCflags other="other miscellaneous nonvalidated flags" >
 CCspeed/speed>
 CConline/online>
 CCmodem/modem>
 CCupdate/update>
 CCcompression/compression>
 CC/flags>

 CC> This is my preference because you're declaring a "block" of common
 CC> elements which are flags that describe things.  Each flag is then named
 CC> based on what it is describing.

OK, I can dig it.

 CC> I have added an attribute called "Other" to the flags tag
which would
 CC> just hold your miscellaneous flags values which are not validated.  You
 CC> could also have:

 CCflags>
 CCothers/others>
 CC/flags>

 CC> And then you could also use a DTD/Schema to validate that field for
 CC> "others" at least contains a comma delimited string of flags.  You
 CC> would not care what their "individual" values are but
that the format
 CC> of the element is CSV.  I think I like this way better just looking at
 CC> it.

OK.

 >> 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
 CC> perhaps
 >> everything could be a child.

 CC> Parsing isn't difficult IMO whether it's an attribute or a child
 CC> element; however again it goes back to structure, validation, and
 CC> readability.

And because of this I think the best way to go is child for almost if not
everything.

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

--- Fidolook Lite FTN stub