Re: The future of XML related technologies in Mozilla

smaug wrote:
> I started to wonder what are
> the "new" XML technologies that should be or could be supported in Mozilla.

What follows are my thoughts based on about 10 minutes of thinking; they're not 
really policy or anything like that.

With that caveat, I think the goal of supporting whatever we support should be 
to advance the Web (in the broad sense of equal/free/easy access to information 
and ability to accomplish things via sharing of information).  Vague, but it 
feels to me like that's what the point of the Mozilla Foundation is.

Now deciding what's going to help "advance the Web" is the hard part.  ;)  As I 
see it, there are several classes of things we should consider supporting even 
if they're not used much yet:

1)  Things that are useful for information interchange and have no reasonable 
(e.g. usable by anyone) alternatives.  The idea here is that once there's a 
critical mass of support for whatever it is, usage will increase.   MathML could 
fall in here, though it's severely hampered by the fact that hand-writing it is 
basically impossible and the professional mathematical community already has 
TeX/LaTeX as an interchange medium.  Generating MathML from TeX is chancy at 
best because the layout models are so different -- simple things map over OK, 
but anything complicated doesn't really.

2)  Things that are as in #1 but have reasonable proprietary solutions.  In some 
ways, SVG falls here (Flash being the proprietary solution).  The goal here 
would again be to allow wider use of the technology.  Compared to items in class 
1, there's more of a market pressure against whatever we'd do here, as well as 
much more difficulty in standardizing something that's appropriate for the Web.

3)  Things that improve our application platform and allow both us to improve 
our products and others to create innovative products based on XULRunner.

Some specific bits of XML technology that we want may have other bits of XML 
technology as dependencies, of course.

Now of the things you list, as far as I can tell the situation is the following:

XPointer doesn't really fall in any of these cases, though the closest fit would 
be class #3, maybe.  In fact, having seen the recent mail about XPointer in 
response to queries about its compatibility with SVG, it seems that doing just 
about anything with XPointer is "compliant", which raises the question of what 
the point of it is.  As far as I can tell the point is to give XML language 
authors a common syntax that they can use to mean different things, which is 
pretty silly.

I don't know much about XML Events, so can't say anything about it.

xml:base I'm really not sure about.  Actually handling it properly (which we 
don't, btw) is hard to do, especially if you want to do it fast.  It seems like 
a nice idea, but over-engineered based on a use case that I'm not seeing people 
use much right now (that of putting together various pieces of automatically 
generated content from different sources into a single document).  This use case 
_does_ seem like something that might be beneficial in the future.  This sort of 
falls in classes #1 and #3.  Of course we'd need to actually make it work 
correctly first.

XLink is pretty much like XPointer, but worse.  Careful reading of the XLink 
spec indicates that pretty much anything you do with it is conformant; email 
from the working group the few times they've deigned to respond to anyone 
indicates that like XPointer the idea is to give XML language authors a syntax 
for defining what a "link" is in their language and a way of expressing how it 
behaves.  Absolutely not provisions are made for real-life authoring situations 
(e.g. various combinations of the XLink attributes, or lack of them as the case 
may be).  Combined with the fact that our XLink implementation is not really 
compatible with what SVG wants out of XLink and the fact that the working group 
routinely takes months to respond to simple clarification queries, I feel that 
we should remove XLink support altogether.  Namespaces that wish to use it will 
need namespace-specific knowledge anyway.

MathML I mostly addressed above.

xml:id might fall in class #3 above.  It really feels like a solution in search 
of a problem to me, though...

I don't know enough about XInclude and SMIL to comment.

XBL2 is an absolute necessity for us in terms of security and class #3 above. 
Whether what we implement is "XBL2" or "Mozilla XBL That's Designed Better" or 
whatever, we need a replacement for the current XBL code...

DOM3 Core has some useful functionality that we have implemented.  It has a 
number of things that are targeted at server-side XML processors that we don't 
really need, except _possibly_ for class #3.  In my opinion, DOM3 Core should 
have been split into at least 2, possibly 3 specifications (Core, XML Workflow, 
and maybe some sort of browser spec).

DOM3 Load/Save is even more slanted towards server-side things than Core.  It's 
not a very usable API -- it makes the edge cases hard and the common cases hard. 
  We ideally need something that makes the common cases easy and the edge cases 
possible.  Something more akin to our DOMParser and DOMSerializer, perhaps.

Validation is not something I can speak about usefully.

 > What are the features we really need and why?

Good question!  Worst thing is that the answer is likely not time-invariant.  ;)

> Who/what is the target audience/user for these technologies; web developers, xul
> app developers, researchers, firefox UI, extension developers, 
> implementators of new XML based languages?

"Yes."  ;)

> Can we somehow measure the need for a feature and say that it is ok to
> implement it if the binary size increases only XXkB. Or that if code is 
> removed elsewhere, new features can be implemented.
> (Performance regressions aren't ever acceptable, IMHO)

This would be interesting to try...  Right now we operate more on a "we've 
decided we need this; let's just do it!" model.

I do suspect that as we add more features binary size growth is unavoidable.  I 
also think that even performance regressions might be OK, depending on the 
benefits and on how the regression compares with user hardware improvements. 
But the benefits would have to be _huge_ here, imo....

> I think Mozilla's support for XML technologies should evolve and maybe 
> we shouldn't always think only web developers. HTML5 doesn't solve all
> the problems ;)

Indeed.  I think the way to start is by identifying the problems we are looking 
to solve, or the infrastructure we need to allow others to identify such 
problems and solve them.

-Boris