[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: DTD parser in c#
> To be honest, if another > company came along and tried to start a new C#/.NET project for SAX I > would be surprised at their willingness to fragment the community and > re-inven the proverbial wheel. Hopefully, the community would ignore it-- > and if not, having the System.Xml would lend a certain precedence for > the API. Pretty limited view. I wrote a SAX parser about 2 months ago using the namespace XmlAdvice.Xml.Sax, and it is going to appear soon within an article that I wrote and as part of a download. And as for precedence, Dan Wahlin put one in his book (one of the most popular regarding XML and .NET) about 2 1/2 years ago, using the namespace XmlParsers.Sax. IIRC, there was a download on another web site that showed how simple it was to write a SAX parser given that the majority of the work was already afforded via the System.Xml.XmlTextReader, that one was available during the first beta of .NET. I agree with Dare that only proper members of the FCL should include the System namespace. Look at the numerous other samples out on the web that avoided using "System" for the root of the namespace name that are not affiliated with a company. -----Original Message----- From: Jeff Rafter [mailto:lists@j...] Sent: Monday, March 29, 2004 3:33 PM To: Bryce K. Nielsen; xml-dev@l... Subject: Re: DTD parser in c# > The reason that was pointed out beforehand, if MS ever decided to create a > SAX namespace. Once that happens and you have two conflicting namespaces, > someone has to change and we all know it's not going to be Microsoft. It's > extremely annoying when that does happen, so it's best for all parties if > the namespace is a bit more unique in the beginning, IMHO. Agreed, that is annoying... but in this case I am not sure it applies. As Dare already said, it is unlikely that MS is going to release it's own SAX package. Additionally, the goal for this particular project is that it be an open and community developed project. Once it is complete, I am sure that the goal of the project is to be recognized by the SAX project proper... then possibly work in conjunction with that group. To be honest, if another company came along and tried to start a new C#/.NET project for SAX I would be surprised at their willingness to fragment the community and re-invent the proverbial wheel. Hopefully, the community would ignore it-- and if not, having the System.Xml would lend a certain precedence for the API. Even if MS decided to release a new SAX implementation in .NET I would hope to see them forbear and instead use the community project. Again in projects like this single-source breeds better interop. Though I am not wedded to the current System.Xml namespace, I am still looking for a better reason to abandon it than that someone _may_ later also try to use it. Which in this case is doubtful. But your recommendation is duly noted-- especially because I like SysOnyx's products : ) Cheers, Jeff Rafter ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://www.oasis-open.org/mlmanage/index.php>
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|