wrote in message news:1041272583.716.0{at}tkdsoftware.com...

> 
>              online=""
>            modem=""
>            update=""
>            compression="">
>  
> 

Since speed and compression are potentially fields we would want to limit to
the validation of only a "given" set of values, these should be child
elements to .  Not sure what modem, online, & update reflect though.

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

XML Schema, most definately!

> I was thinking something along these lines:
>
>               ITN=""
>            IBN=""
>            IFC=""
>            ITX="">
>   
> 
>
> 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...

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

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

  
    33600
    whatever
    whatever
    whatever
    V32B,V42B
  

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

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

  
    Other_Flags
  

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

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

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

Thanks
Chris



--- Mail-ennium/32 v1.01.301.9/#01-0001