[
Lists Home |
Date Index |
Thread Index
]
> 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@jeffrafter.com]
Sent: Monday, March 29, 2004 3:33 PM
To: Bryce K. Nielsen; xml-dev@lists.xml.org
Subject: Re: [xml-dev] 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>
|
