[
Lists Home |
Date Index |
Thread Index
]
> 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
|
