Vote: deprecate std.xml?

H. S. Teoh hsteoh at
Fri Jan 17 18:54:21 UTC 2020

On Fri, Jan 17, 2020 at 09:50:52AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 1/17/20 2:01 AM, Alex Burton wrote:
> > It works well, and resulted in large performance increases.
> > 
> > It would be great if something like dxml was in the standard
> > library.
> > 
> I think the biggest stumbling block was something like schema
> validation. I can't remember the exact details but Jonathan did not
> want to include it because it's a security concern. Something in
> Phobos shouldn't ignore a large part of the standard.

No, I don't think it was because of security, it was more because of
performance, because the current implementation of dxml uses slicing
extensively to avoid needless copying of data. But to validate a schema
according to spec, esp. some of the more obscure (and convoluted)
corners of the spec, you'd need to pre-parse the whole thing and
allocate a bunch of stuff before you can run the validation.

The other stumbling block is entity support, which again has some
rarely-used corner cases in the spec where they can recursively expand
to arbitrarily large content (IIRC it may even involve network access or
at least local filesystem access[*]) that may entirely change the
meaning of subsequent characters (and resulting parse tree). This would
make the current slices-based API impossible, which kinda undermines
dxml's entire underlying premise.

([*] Yeah, the XML spec is IMNSHO the epitome of design by committee
producing an insanely-overengineered over-complex system, most features
of which normal people never use or are even aware of.)

The ironic thing is that the cases that dxml *does* support are the only
cases that 99% of XML users would ever actually need. Yet there's that
annoying 1% of obscure and insanely-complex corner in the spec that
*some* people out there actually expect to work, which prevents us from
saying that dxml implements the entire XML spec.  And Phobos being the
epitome of perfectionism, this means dxml will likely never make it in.
Or if it does, it's almost guaranteed that *somebody* will barge in and
complain loudly about how std.dxml doesn't *actually* implement the XML


Designer clothes: how to cover less by paying more.

More information about the Digitalmars-d mailing list