Cart
[Home] [By Thread] [By Date] [Recent Entries]
I'd have to say from the tool building perspective, I'm disappointed so far with what I am seeing of DTD support in system.xml from Microsoft. OTOH, I'm just refamiliarizing myself with system.xml and I may have missed some important knowledge base articles. There is a tendancy to think DTDs went the way of the dodo. In MIL land, this simply isn't true. DTD design is advanced and has produced workable by quite complex expressions. One can chop these down to minceable nuggets (eg, at the work package level), but then getting these into validatible form and validating input coming from non-XML authoring tools (say Word) becomes a significant challenge. IOW, I think of these questions in terms of the toolkits and frameworks, the notion being if an interface, human or otherwise, can get me documented well-formed XML, I can do the rest but I still have to live with the GFI. Sometimes the harder problem is explaining that to the technical writers and their managers who still want to believe a well-styled manual is a good one. len Quoting Norm Birkett <Norm.Birkett@r...>: > Which leads me to a question for the list: Have you observed any tendency > among software developers to slight the design of XML languages, by > comparison with other interfaces (such as database schemas or APIs)? > > If so, do you think that's because they suppose that tagged data is > somehow easier to change at the schema level than non-tagged data? > > (I ask because I'm trying to get a sense of how software engineers tend > to think about XML schemas, and you all have WAY more experience with this > than I do.) > > Norm Birkett
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
