307813 - Stop inflexibly requiring namespace declarations for SVG

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Ted Gould]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

When opening this file I get a prompt for an application to use for reading this
file.  It is an SVG file, and opens fine in Inkscape.  Ironically, the
application that it is prompting me to use is the Adobe SVG viewer.  I tried
both off the net, and locally after downloading the file.  I tried putting the
file into a custom HTML page that referenced it with no luck.

Reproducible: Always

Steps to Reproduce:
1. Open the file

Actual Results:  
It prompts me for an application to use in order to view the file.

Expected Results:  
Displayed a graph of elevations.

Comment 1

[Jonathan Watt [:jwatt]]

The reason is that gpsvisualizer.com sends "image/svg-xml" instead of
"image/svg+xml" as the MIME-type for SVG. The thing to do is contact the sys
admins for that site and get them to configure their servers correctly.

Comment 2

[Jonathan Watt [:jwatt]]

See http://jwatt.org/svg/authoring/#server-configuration for more info BTW.

Comment 3

[Ted Gould]

Okay, so their server is incorrect.  But, saving it to my computer, and doing a
"File->Open" produces the same result.

Comment 4

[Ted Gould]

http://openclipart.org/clipart//food/bread_and_wine_mark_near_.svg

Proper MIME type sent, this file doesn't get detected as an SVG also.

Comment 5

[tor]

Missing namespace in document - see
http://jwatt.org/svg/authoring/#namespace-binding .

Comment 6

[Ted Gould]

Yes, it does not include a namespace definition.  I don't believe that SVG
documents require one to be valid SVG documents.  It does include the <!DOCTYPE
header to specify that it is an SVG document.  Also, it is valid XML with <svg>
as its root element.

I think that all of these should be used as means to detect whether a document
is an SVG document, and thus rendered as such.

Comment 7

[Ted Gould]

Attachment: Bread and Wine file

Attaching the file incase it gets change on openclipart.

Comment 8

[Holger Will]

Hi Ted

(In reply to comment #6)
> Yes, it does not include a namespace definition.  I don't believe that SVG
> documents require one to be valid SVG documents.  

indeed SVG files dont need a namespace to be valid, but if there is no namspace,
the document might be an SVG document, but the elements are not SVG elements,
that means nothing gets rendered.

> It does include the <!DOCTYPE
> header to specify that it is an SVG document. 

you are right, in that a DTD enables you to set a default namespace (which is
allways required), but this only works, if the DTD is read and interpreted ,
which in turn is only required by a validating parsers ( XMLSpy for example ),
but SVG renderers so far do not validate the content. 

> Also, it is valid XML with <svg>
> as its root element.

you are right again, but if there is no namespace, its not an <svg:svg> root
element, but a <null:svg> element, and that can mean anything... you have to
provide a namespace to tell the parser what you mean.
you can take a look for example at the OpenClipArt.org metadata, there is a
<dc:title> element, and its purpose and meaning is different to <svg:title>.
with the namespace you provide the meaning.

> 
> I think that all of these should be used as means to detect whether a document
> is an SVG document, and thus rendered as such.

i guess the important part is not that its an svg document, but the document
contains svg elements, and this is only possible with a namespace.

by the way, if the DTD would be handled correctly, the file would again be
invalid, since the metadata used in the file is not mentioned in the DTD. you
would have to extend the original SVG DTD with the description of the OCAL metadata.

Comment 9

[Jonathan Watt [:jwatt]]

Holger is partially right, but I want to correct some of the things he said and
give some more information.

SVG is namespaced XML. If you're writing SVG content you absolutely must declare
the namespaces you use - it's been that way since SVG 1.0, and it will continue
to be that way in future. Where the confusion comes from is that draft versions
of SVG 1.0 defined the namespace(s) in the DTD. Therefore in a validating parser
(one which parses the DTD) it would be unnecessary to declare the namespaces in
your SVG content. The problem with this of course is that SVG impelementations
are not required to be validating parsers (Mozilla and ASV are not for example).
Realising this issue, the SVG WG removed the declaration from the DTD before SVG
1.0 was released.

Declaring the namespace in your content isn't even an issue of being valid. It's
more fundamental than that. If you don't declare the namespace, your content
*isn't even SVG*. Placing your content in a namespace is what makes it what it
is. That's what's required by the Namespaces in XML recommendation:

  http://www.w3.org/TR/REC-xml-names/

and conformance to the Namespaces in XML recommendation one of the requirements
of the SVG recommendation:

  http://www.w3.org/TR/SVG10/conform.html#ConformingSVGDocuments

While ASV only has to deal with SVG, Mozilla has to deal with multiple
namespaces (XHTML, MathML, XBL, SVG, ...) and be able to deal with them in the
same document. DTD's are useless in mixed namespace environments, and indeed
their problems have been one of the reasons behind the SVG WG's decision to stop
using them starting with SVG 1.2. (Actually they've been encouraging people to
stop using them in SVG 1.0 and SVG 1.1 too if you look at the [e-mail]
archives.)

I hope this has gone some way to explaining why you must declare the namespaces
of your content, and why Mozilla won't just parse a file as SVG because it has
an SVG DTD. We are backed on this not only by the SVG WG, but also by a member
of the SVG WG who was heavily involved in the creation of ASV. ;-) See

  http://groups.yahoo.com/group/svg-developers/message/51710

Comment 10

[Ted Gould]

I appreciate everyone's opinion, but I respectfully disagree.

You're making a technical argument for something that will end up being a
political discussion.  When users see that something works with Adobe SVG or
Opera, but not with Firefox, they aren't going to think that their SVG file is
incorrect.

Beta is still the better format, VHS won.  And Firefox still renders some really
bad HTML.  Stuff that was done by Netscape to make it so that webpages just
work.  I know it kills the XML guys, but I can do "<i>my <b>text</i> here</b>"
and it will render.  The render understands what I'm trying to do there.  I
would argue that the same approach should be taken by the SVG renderer.  As far
as I'm aware, no other XML language has an "svg" tag, it would seem when that
tag is seen, the SVG namespace can be assumed as the default for the content
that follows.

You're not going to win friends by being more correct, you'll win friends by
being more helpful.  I would recommend having an option like XHTML/strict that
people can use to validate their files, but not being tolerant of common
mistakes will just make people not consider your implementation useful.

Comment 11

[Jonathan Watt [:jwatt]]

Okay, let's make this *the* bug for discussing whether or not we should require
namespaces to be declared for SVG under all circumstances. I'm CC'ing lots of
people to try and make sure we can have this conversation once and for all.

The declarations that we require but which are so often missing or broken are:

  xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink"

and possibly in the future if XML Events becomes more widely used:

  xmlns:ev="http://www.w3.org/2001/xml-events"

This is causing a lot of problems, complaints and concern. I'm not sure yet
exactly what an acceptable proposal for resolving the issue should be, but lets
start with the following and work from there.

If we end up parsing a file as XML and find that it has an SVG 1.0 or SVG 1.1
doctype declaration and that root tag is 'svg', we should bind the SVG namespace
as the default namespace, and bind the XLink namespace to the namespace prefix
'xlink' before we parse any of the root element's attributes. That way if the
default namespace is declared by the content, or if a namespace is bound to the
'xlink' namespace prefix our settings will be overridden.

I've been speaking with a number of people about this for a while now, but
rather than express their thoughts and opinions second hand I'd appreciate if
they could add them here themselves.

Comment 12

[Jonathan Watt [:jwatt]]

It's been pointed out to me that some SVG content out there doesn't have a
doctype declaration or namespace declarations. Also members of the SVG WG have
been encouraging people to remove doctype declarations from their SVG. (And for
the record SVG 1.2 will not have a doctype.) Perhaps we shouldn't even require
an SVG doctype?

Comment 13

[Doug Schepers]

I think it is essential that Mozilla require the correct namespace declaration.
A few (of many) reasons are below:

1) If a file is found in the wild (such as on a local file system), without a
proper MIME Type, the processor must have some way of discovering what the
content is supposed to be; while I am not aware of any other 'svg' tag, for
example, there could easily be one (perhaps it is a part of a manufacturing XML
and means 'strict vendor guidelines'... in a multi-namespace document, how is
the UA to process this?);

2) SVG itself, in the near future, will likely be used as a rendering format for
custom XML using sXBL; in this case, you are very likely to see elements that
are in both namespaces ('title', 'desc', 'line', 'a', 'g', 'path', and 'image'
are all likely suspects for one reason or another); SVG should not be exempt
from a general policy of namespace declaration, even as the root element;

3) Arguments that content like "<i>my <b>text</i> here</b>" should be allowed
are missing the point that this is essentially arguing that we should let XML
not be XML and make assumptions on what is intended; when HTML was the only
common markup language, certain assumptions could be made, but this problem
becomes exponentially harder the more markup languages we use; as a content
author, I want to code once and have it render the same everywhere, and that
will not happen if assumptions are made by each UA implementor about the best
way to display content... this argument is particularly compelling due to the
common use case of SVG as a front end for WebApps, where rendering decisions are
not merely expressed as text (which can be understood even with imprecise
styling), but as programmatic objects that need precision;

4) If authoring tool creators don't receive a clear message that bad content is
unacceptable, they will not correct their tools;

5) It's easy to do. It's one line. 

I am making the assumption that this bug was filed out of frustration that a
popular (and very good) tool's content was not rendering as expected. The
reporter should be aware, though, that art is only one use case for SVG, and is
arguably not the strongest business case for it. If this looseness is allowed
into an increasingly mixed namespace environment, the repercussions are going to
be very harmful to the development of the Semantic Web and WebApp environments.
The proper place to file this bug is with the authoring tool developers, asking
them to create proper content (especially as most graphical SVG tools,
themselves, now use lots of namespaced elements in the SVG for roundtripping ).

Comment 14

[Brendan Eich [:brendan]]

Hi, jwatt asked me to weigh in with some thoughts.

Briefly, I think form should follow malfunction, and learn from it.  Micah
Dubinko (most recently at
http://dubinko.info/blog/2005/04.html#perm2005-04-15_namespaces and in previous
posts and talks) and others have summarized the real-world usability bugs in XML
namespaces that have evidently come up again (Micah's experience was with XForms
users) with SVG:

- Namespace declarations are opaque to readers and typo-prone to writers.
- People forget to qualify.
- People forget the default, if there is a default (XPath).

The first one is apparently so big a usability hazard that it actually results
in people not merely misspelling, but leaving off entirely, such long-winded and
redundant-seeming declarations from what is obviously an SVG file, when they can
get away with doing so.  Which they can, with the most popular *shipped* SVG
viewers.

It doesn't matter whether an XML declaration is "only one line".  In reality,
many people have problems getting 'em right, never mind using the declared
prefixes correctly.

Larry Wall famously said "As we all know, reality is a mess".  He depicted this
(http://www.perl.com/lpt/a/1998/08/show/onion.html).  Then he said:

"It's certainly a picture of how Perl is organized, since Perl is modeled on
human languages. And the reason human languages are complex is because they have
to deal with reality."

Human languages don't tolerate the verbosity and (in most cases) redundancy of
something like the two XML namespace declarations required by SVG per spec.

Computer scientists may like such things, at least when specifying XML languages
and writing programs that consume XML.  Most humans don't.  The idea that SVG
will always or even mostly be generated by elves, or magically free and perfect
tools, is not much more realistic than the idea that HTML or some next-gen XHTML
will be.  The web is a mess, because reality is a mess -- and most people, and
successful computer languages, can and do cope.

You can call me names for defying the sacred XML namespaces standard, but I've
got reality on my side ;-).  Let the solution fit the problem.  Make computers
work harder, not humans, unless there is ambiguity -- and disambiguate by
favoring conciseness and sane defaults for the common cases.  Make the abnormal
cases pay with verbosity.

So I say, since the currently popular SVG viewers tolerate lack of XML namespace
declarations, we should too.  Otherwise, we will punish users for the sins (if
sins they be) of content authors.

Now, you may object: Firefox has much greater market share than any existing SVG
viewer.  My response is still "so what?"  Firefox 1.5 can't cause authors to fix
their pages by punishing Firefox's users.  Only if all SVG authors were to test
in Firefox, and we didn't fix this bug, *and* we somehow got authors of existing
content to come back from their next gig, or next life, and fix all of their
already-created content, ....  You can see the odds are not good when multiplied
out.

In this I am agreeing with Ted Gould.  But sorry Ted, Betamax wasn't better than
VHS -- that's an urban myth.  See
http://www.guardian.co.uk/online/comment/story/0,12449,881780,00.html -- there
are some lessons there for XML namespaces, and for SVG.

Also, regarding Ted's statement, accurate as far as it went, that

"Stuff [...] was done by Netscape to make it so that webpages just work."

Marc Andreessen recounted to me how well before Netscape, even when the number
of web servers hit by NCSA Mosaic was below 100 sites, Mosaic hackers learned
from user mistakes in HTML authoring, and added quirks support.

I know, this led to tag soup, which is the Greatest Evil Ever Visited Upon
Mankind.  Nevertheless, inferring SVG's two required XML namespaces without
requiring their declaration is not evil.  Much. ;-)

/be

Comment 15

[Cameron McCormack (:heycam)]

As a point of comparison, I'd like to point out what Batik does and give a few
opinions of my own.

Since 2002
(http://svn.apache.org/viewcvs.cgi/xmlgraphics/batik/trunk/sources/org/apache/batik/dom/svg/SAXSVGDocumentFactory.java#rev200855)
 Batik has assumed an xmlns="http://www.w3.org/2000/svg" on the document element
if it doesn't have their own default namespace declaration.  This was actually a
surprise to me, since Batik is usually pretty strict about such things.  Despite
the line of code there that attempts to predeclare the xlink namespace, omitting
the xlink namespace declaration will cause an error when attributes with names
such as "xlinK:href" are used.

*a while later*

Ok, I just wrote a bunch of text outlining some possible technical reasons why
you would allow a namespace default that's not specified by an xmlns attribute
(or indirectly via the DTD).  But it really was just clutching at straws. 
Technically, I don't think it is justified.

Since compound documents will become increasingly important on the web, I think
namespace issues will be harder to ignore.  But I think there is one place where
an implied namespace declaration could be allowed, if the so-called political
justification could be made for violating the Namespaces in XML rec, and that is
for documents sent with an image/svg+xml MIME type (or for non HTTP situations,
such as loading from disk, using whatever platform specific method is typical
for guessing file type (e.g. extension)) whose document element's name is "svg",
as long as there is no xmlns declaration on that element.  My reasoning is that:

  - If the MIME type is image/svg+xml, then the resource is intended to be
    an SVG document.
  - SVG documents must have an element called
    {"http://www.w3.org/2000/svg", "svg"} as the document element.
  - If the UA knows that it should be an SVG document from the MIME type,
    there is no possibly correct behaviour that is being missed from not
    processing the document element as an element in no namespace.

I think assuming an xlink namespace declaration is not acceptable, since there
is no relationship between the type of document being processed and the xlink
prefix (except that SVG documents commonly declare the XLink namespace with the
prefix "xlink", but that's a poor reason to assume it).

Having said that, I believe the correct course of action is to require an
explicit namespace declaration.  In the long run, authors will have to get their
namespaces correct for compound documents by inclusion.  You may as well get
them used to it now.

BTW I like the idea of flagging the error of the lack of namespace declaration.
 Perhaps using something like the "This page needs a plugin which is not
installed" bar that is displayed in Firefox?

Now, to mull over the idea of changing Batik's behaviour... :)

Comment 16

[chris]

As we move forwards into compound documents, namespaces become more obviously
valuable. However, well formedness requires that namespace prefixes be declared
and well formedness, hopefully, is the minimal bar and not up for discussion.
But we are going to see more mixed XHTML/SVG, XForms/SVG, etc and thus,
namespace prefixes.

Early drafts of SVG put the namespace prefixes into the DTD, which is why old
products like ASV support that. Its incorrect, thouh, and was corrected before
SVG 1.0 went to Rec.

Firefox is quite correct to require the namespace. When loading from local disk
(no MIME types) and with DTDs going away since they are largely useless, the
namespace declaration is the only reliable label.

Comment 17

[Peter Van der Beken [:peterv]]

So this particular bug is really much more limited in scope than some want to
turn it into :-).
There's two obvious solutions. Short term: add a mapping of the old SVG 1.0
doctypes to local DTDs
(http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/parser/htmlparser/src/nsExpatDriver.cpp&rev=3.80&root=/cvsroot#209).
Longer term: get my fix for bug 22942 finished.

Comment 18

[Ted Gould]

Wow, this turned into a lot larger discussion than I'd imagined.  Thank you
everyone for your time.

I think that the quirks mode should only be applied when "the SVG is the
document", not when the SVG is embedded in another XML structure.  I know I
mentioned that earlier, but I think I was wrong in suggesting that.  I'm not
sure if this distinction is made in the Mozilla codebase, but I think it is a
useful one.  At least for the first experimentation for most users, I think SVGs
will be used with <img> and <embed> tags, not embedded in the document.  I don't
know of an SVG editor that will allow you to edit SVGs inside another document
(though on Inkscape we're working towards that).  I think this case should be
made as simple as possible.

Personally, I know when I write a quick SVG using a text editor, I rarely
include the namespace.  I know this is me being lazy, but I just want to do
something quickly, so I put a couple of rectangles in, or include a couple of
JPEGs to make a compound image.  Then, I usually either include this in another
SVG or HTML document.

So, in the end, I'm advocating a quirks mode that would allow for, in simple
cases, the namespace declaration to be omitted.  I don't know how easy this is
to implement, I've never looked at the Mozilla codebase, but I do think it will
ease SVG adoption on the web.  And that, is something that I'm very interested in.

Lastly, on Betamax.  "Betamax recorders use a slightly larger head drum than VHS
recorders, yielding slightly greater video bandwidth as the video signal is
recorded over a longer stripe."  http://en.wikipedia.org/wiki/Betamax  But, I
would entirely agree that VHS was the stronger overall system.  And I believe,
that adding this quirks mode for simple cases will make Firefox a stronger
overall system.

Comment 19

[chris]

"quirks mode" - just say no. Why screw up a nice design just because a couple of
early, pre-rec implementations tolerate an incorrect syntax?

Comment 20

[Holger Will]

(In reply to comment #18)

> Personally, I know when I write a quick SVG using a text editor, I rarely
> include the namespace.  I know this is me being lazy, but I just want to do
> something quickly, so I put a couple of rectangles in, or include a couple of
> JPEGs to make a compound image.  Then, I usually either include this in > another
> SVG or HTML document.

Ted, have you thought about the usecase, that a user might want to download an
image from OCAL, and then include it inline of an XHTML Doc, the result would be
that he might have to edit the file ( include the namespaces ) by hand, to make
it work. if however, the namespace is allways given on the root element, you can
allways use the document, as a document fragment of a combound document without
a problem. so with respect to OCAL i would consider adding the correct namespace
as best practise, no matter what the result of this discussion may be.

Comment 21

[Ted Gould]

(In reply to comment #20)
> so with respect to OCAL i would consider adding the correct namespace
> as best practise, no matter what the result of this discussion may be.

I entirely agree.  I'm not worried about projects like OCAL, I know the people
who are doing OCAL understand XML namespaces.  But, I know a lot of people who
understand the principles of XML, but have never heard of namespaces.  Or worse
yet, those who kinda learned XHTML from HTML (enough to make the validator pass)
and thus believe they know XML.  I think when you try to make compound
documents, you realize the problem and look for XML namespaces.  Those who have
never thought of compound documents have never looked for a solution to its
problems.

In a nutshell, I'm less worried about tools and people that understand XML and
generate SVG.  I'm worried about people using PHP to generate their own SVG
files and don't really understand XML.

I'll write an e-mail to the OCAL list about the namespace being added as part of
the validation.  All OCAL files should include the namespace.

Comment 22

[Doug Schepers]

(In reply to comment #14)
> - Namespace declarations are opaque to readers and typo-prone to writers.

They are opaque to most readers. There are 2 exceptions I can think of:
1) Readers who are trying to become writers, and who look at the source of other
files to learn by example, in which case the source is better if it teaches them
correctly;
2) Readers that are not human, such as accessibility apps; such applications may
be relying on an indicator of which syntax to adapt to the appropriate medium
(say, speech).


> It doesn't matter whether an XML declaration is "only one line".  In reality,
> many people have problems getting 'em right, never mind using the declared
> prefixes correctly.

Most people who are authoring SVG for the purpose of art will likely be using a
drawing app, and those apps should know to author correct documents. The only
people who need concern themselves with the technical guts of an SVG document
are those who are going to be authoring it by hand (such as people using it for
tech reasons like building WebApps) are those who would do well to know the whys
and wherefores. But they don't even need to... you can set up most authoring
environments to provide you with a working template to use, and you don't even
really need to know what it means, just that it works. 

 
> Human languages don't tolerate the verbosity and (in most cases) redundancy of
> something like the two XML namespace declarations required by SVG per spec.
> 
> Computer scientists may like such things, at least when specifying XML languages
> and writing programs that consume XML.  Most humans don't. 

Well, I'm not a computer scientist, but I do study linguistics. Human languages
are full of seemingly arbitrary declarations. For example, in English, we
require that you preface many statements with "It is" (It is raining, it is
cold, it is unacceptable that SVG documents not have a namespace declaration),
even though there is no "it" to be "is"ed; many other languages do not require
this structure in the same way. We also have 3 separate pronouns for each gender
(he and him and himself, she and her and herself) to mark location and role in
the sentence; this is not common in most languages, and is a frequent mistake
made by children; but it persists because it is useful in disambiguating
intention (think of the sentence, "He gave it to himself" and plug in the
various options there... it's quickly obvious that it's a necessary feature). Or
look at other human languages, where they require a gender be assigned to
clearly sexless things like chairs and bridges, and often have extremely
elaborate rules for constructing sentences dealing with objects of that
particular gender. All this may seem off-topic, but it's not... it highlights
the need for disambiguation in markup.



> You can call me names for defying the sacred XML namespaces standard, but I've
> got reality on my side ;-). 

Apostate fiend!!! 


> Let the solution fit the problem.  Make computers work harder, not humans, 

I think that's a laudable goal, but misplaced in this instance. The amount of
work to be done by humans here is miniscule, and it serves the purpose of
teaching them about namespaces, while preventing other humans (UA implementors)
from doing way too much work reading the minds of future authors.


> unless there is ambiguity -- and disambiguate by
> favoring conciseness and sane defaults for the common cases.  Make the abnormal
> cases pay with verbosity.

I think that in the near future, single-namespace documents will be the abnormal
case.


> So I say, since the currently popular SVG viewers tolerate lack of XML namespace
> declarations, we should too.  Otherwise, we will punish users for the sins (if
> sins they be) of content authors.

I think perhaps one sane approach might be to render the content, but warn the
reader that there is a problem with the document; this warning could be as
obnoxious as a popup dialog, or as inobtrusive as a status-bar message. This
would let authors know that they are being sinful, and also give a clue to users
why some unexpected behavior might be exhibited, so they can tell authors.

Comment 23

[Brendan Eich [:brendan]]

(In reply to comment #22)
> (In reply to comment #14)
> > - Namespace declarations are opaque to readers and typo-prone to writers.
> 
> They are opaque to most readers. There are 2 exceptions I can think of:
> 1) Readers who are trying to become writers, and who look at the source of
> other files to learn by example, in which case the source is better if it
> teaches them correctly;

The abnormal case around which the normal case should not be bent.

> 2) Readers that are not human, such as accessibility apps; such applications
> may be relying on an indicator of which syntax to adapt to the appropriate
> medium (say, speech).

I meant human readers, of course.

> you can set up most authoring
> environments to provide you with a working template to use, and you don't even
> really need to know what it means, just that it works. 

Yet there's enough content out there that lacks well-formedness with respect to
namespace declarations that we have this bug.

[linguistic stuff that I agree with, but that is not really apposite here,
snipped.  I can defend all sorts of dying English usage on disambiguation
grounds, but such usage is still dying.  Lazy humans!]

> All this may seem off-topic, but it's not... it highlights
> the need for disambiguation in markup.

That's why I already wrote "unless there is ambiguity -- and disambiguate by
favoring conciseness and sane defaults for the common cases."

> I think that's a laudable goal, but misplaced in this instance. The amount of
> work to be done by humans here is miniscule,

Micah cites evidence to the contrary, and this bug reports signs of the same
problem in another XML language.  Where is your evidence?

> and it serves the purpose of teaching them about namespaces,

Trying to teach pigs to sing just annoys 'em.

> while preventing other humans (UA implementors)
> from doing way too much work reading the minds of future authors.

Agreed, let's not create ambiguity.

> I think that in the near future, single-namespace documents will be the
> abnormal case.

I'll bet real money otherwise, if we are talking about the web and not some
intranet or equivalent.

> perhaps one sane approach might be to render the content, but warn the
> reader that there is a problem with the document; this warning could be as
> obnoxious as a popup dialog, or as inobtrusive as a status-bar message. This
> would let authors know that they are being sinful, and also give a clue to
> users why some unexpected behavior might be exhibited, so they can tell
> authors.

Users generally don't contact authors, or even [e-mail].

The status bar is ignored too much, anti-phishing research says -- but again, in
the mass-market Internet, there's no value in passing errors to users.  Errors
should be concealed as much as possible.  Authors who need spanking need design
time spanking extensions to their browsers, strict options, etc.

/be

Comment 24

[Doug Schepers]

(In reply to comment #23)
> (In reply to comment #22)
> > (In reply to comment #14)
> > > - Namespace declarations are opaque to readers and typo-prone to writers.
> > 
> > They are opaque to most readers. There are 2 exceptions I can think of:
> > 1) Readers who are trying to become writers, and who look at the source of
> > other files to learn by example, in which case the source is better if it
> > teaches them correctly;
> 
> The abnormal case around which the normal case should not be bent.

I don't think it's an abnormal case. I think it's a very common case. Most
people I know who have learned SVG (and HTML, for that matter) have learned the
facts and the best practices from looking at other content. That's a large part
of the reason the Web is a success.


> > 2) Readers that are not human, such as accessibility apps; such applications
> > may be relying on an indicator of which syntax to adapt to the appropriate
> > medium (say, speech).
> 
> I meant human readers, of course.

Yes, which is why I pointed out the very important non-human readers which
interpret and transform content for those who can't consume the original content.


> > I think that's a laudable goal, but misplaced in this instance. The amount of
> > work to be done by humans here is miniscule,
> 
> Micah cites evidence to the contrary, and this bug reports signs of the same
> problem in another XML language.  Where is your evidence?

Sorry, I didn't see any evidence by Micah... not that there isn't any, but the
post you linked was rhetoric, not technical.

I've already stated my evidence that it's easy. You can do it 2 ways:
1) by making authoring tools that Do The Right Thing (in which case it's
automatic, and the author doesn't have to care or think about it);
2) by changing 1 line in your template file: "<svg
xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'>"
instead of "<svg>".


> > I think that in the near future, single-namespace documents will be the
> > abnormal case.
> 
> I'll bet real money otherwise, if we are talking about the web and not some
> intranet or equivalent.

Sorry, being so SVG-centric, I didn't fully state my argument. I meant to say,
"I think that in the near future, single-namespace documents *that use SVG* will
be the abnormal case."

This is because SVG + HTML is a great use case, and I think that SVG + XML +
sXBL will be a very powerful tool. There is also the fact that authoring tools
insert their own roundtripping and/or annotation code in their own namespace. I
don't think most upcoming SVG content will be exclusively SVG.

With those restated terms, I'll bet you 5 bucks I'm right. ;)


> The status bar is ignored too much, anti-phishing research says -- but again, in
> the mass-market Internet, there's no value in passing errors to users.  Errors
> should be concealed as much as possible.  Authors who need spanking need design
> time spanking extensions to their browsers, strict options, etc.

A fair point. But I see no harm in it, and I *have* gotten feedback before from
clients about messages in the status bar, so they are paying attention.

Comment 25

[Brendan Eich [:brendan]]

(In reply to comment #24)
> > > 1) Readers who are trying to become writers, and who look at the source of
> > > other files to learn by example, in which case the source is better if it
> > > teaches them correctly;
> > 
> > The abnormal case around which the normal case should not be bent.
> 
> I don't think it's an abnormal case. I think it's a very common case. Most
> people I know who have learned SVG (and HTML, for that matter) have learned
> the facts and the best practices from looking at other content.

That explains all the top browsers supporting so many quirks, indeed!

> That's a large part of the reason the Web is a success.

I agree, if you are talking about "best practices" including quirks, copy-paste
"authoring", and sporadically testing only "what works in the most popular
couple of browsers".

Another reason for the web's success is the hated but necessary ways in which
popular browsers tolerate human errors that were never specified by standards
bodies as best practices, or even as error inputs subject to well-defined error
recovery.

> > Micah cites evidence to the contrary, and this bug reports signs of the same
> > problem in another XML language.  Where is your evidence?
> 
> Sorry, I didn't see any evidence by Micah... not that there isn't any, but the
> post you linked was rhetoric, not technical.

Micah has written and talked about this problem, e.g. at the w3c compound
document and web app workshop in 2004, in terms of the most common mistakes he
has seen XForms authors make.  His testimony is semi-quantitative, and
authoritative with me at any rate.

> I've already stated my evidence that it's easy. You can do it 2 ways:
> 1) by making authoring tools that Do The Right Thing (in which case it's
> automatic, and the author doesn't have to care or think about it);
> 2) by changing 1 line in your template file: "<svg
> xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'>"
> instead of "<svg>".

If it's easy, why was this bug filed?  If the problem is content generated by a
few bad tools, or reliance on doctype loading, and we can ignore these issues,
great -- I'm being provocative on purpose here, so you can ignore me, build a
consensus to WONTFIX this bug, and mark it so.

But the problem motivating this bug didn't seem to be just a few bad tools, and
Ted (at least) argued for this bug to be fixed independent of that issue.

> With those restated terms, I'll bet you 5 bucks I'm right. ;)

Define "near future" as "in the next two years" and stipulate "web, not
intranet" by agreeing that this mixed-namespace XHTML/SVG/sXBL content works in
the top two most popular browsers (among all platforms: mobile, handheld, or
desktop), and I will take that bet, or one for bigger money.

If MS does support SVG and sXBL, I will probably lose, because Firefox will
probably be #2, and we will probably support such content.  If the "mobile web"
utopia arrives, and it's really a web (and not data coffins slaved to their
single carrier, walled-garden-content motherships) I will lose.  Good odds in
your favor, right?  Not in my book.

/be

Comment 26

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ok, I'll weigh in on this one too.

I actually think that we should keep requiring the namespace. However, I would
be ok with relying on the DTD to provide it for us. Either by fixing bug 22942
or by specialcasing the svg dtd somehow as a temporary hack until that bug is fixed.

The reason I don't think we should rely on the mimetype is that mimetypes are
hard enough for people to get right as it is. We'd end up in situations where an
svg file works fine when served from one server, but when downloaded locally or
put on another server it'd "unexplainably" stop working.

So mostly I think it's a matter of making it easy for people to understand how
to get it right.


And as has been brought up before, going forward we'd probably have to require
the namespace anyway. Since SVG1.2 doesn't have a doctype and svg documents are
not unlikly to be compound documents proper namespace declarations are probably
going to be required sooner or later anyway.

Comment 27

[Jonathan Watt [:jwatt]]

Removing bug URL link since server misconfiguration means we wouldn't render
that file anyway.

Comment 28

[Jonathan Watt [:jwatt]]

Comment on attachment 195841 [details]
Bread and Wine file

Marking attachment obsolete since we will definately not be making changes to
allow files with a root <svg> tag to be recognised as SVG when they have
neither an SVG doctype declaration NOR namespace declaration(s).

Comment 29

[Jonathan Watt [:jwatt]]

Attachment: patch

Here's that hack. This will provide default values for the 'xmlns' and
'xmlns:xlink' "attributes" on the 'svg' element if (and only if) we end up
parsing a document as XML and it has a doctype declaration with one of the
following public identifiers.

"-//W3C//DTD SVG 1.1//EN"
"-//W3C//DTD SVG 1.0//EN"
"-//W3C//DTD SVG 20001102//EN"
"-//W3C//DTD SVG 20000802//EN"
"-//W3C//DTD SVG 20000629//EN"

Comment 30

[Elmar Ludwig]

*** Bug 313576 has been marked as a duplicate of this bug. ***

Comment 31

[Brendan Eich [:brendan]]

Continuing my quixotic campaign against XML namespace usability bugs: have a look at http://osteele.com/archives/2004/08/unqualified-imports-for-xml and see whether you don't agree that the world would be a better place if XML supported something like unqualified import.

I'm not advocating violating well-formedness (not seriously, anyway).  I am advocating an extension to well-formedness that improves usability.  If I had time and faith in the process, I'd go to the relevant standards bodies.  That may yet happen, but I thought I'd use the bug to solicit some thoughts first.

/be

Comment 32

[Hixie (not reading bugmail)]

I think we should not take this patch. What we're doing today is correct. SVG files must gave namespace declarations to be conforming. We know this, the working group agrees with this, heck even the chair of the group asked us in this very bug to not provide a hack for non-conformant content.

To me it seems the majority of the people on this bug don't want to do this. Brendan rightfully points out that namespaces as designed have big issues, but that's a separate discussion and should IMHO not affect the immediate outcome of this bug.

Mozilla is likely to be the biggest SVG UA on the market in terms of installed userbase. We should use this position to force authors to do the right thing. We have an opportunity here to reduce the number of undocumented hacks that browsers have to deal with. Let's not worsen the situation!

Comment 33

[Elmar Ludwig]

*** Bug 319577 has been marked as a duplicate of this bug. ***

Comment 34

[P. Damian Cugley]

This bug (or rather its reverse) might be better addressed as an evangelism issue.  The Mozilla SVG page could have a prominent link early in the page addressed to SVG authors faced with the task of porting old content to be Firefox-savvy: both correcting the bad advice given a few years ago based on old drafts of the SVG recomendations, and fixing problems caused by widely-deployed, non-conformant authoring tools.  At present one has to scroll down through a long page to find the FAQ link and then search the FAQ page for fairly technical information.  I understand it, but non-XML-savvvy web editors might not.

If we had a table of bad editors saying things like ‘Acme SVG Pad versions 0.9 and 1.0 generate non-conformant SVG; upgrade to version 1.1, and download _this_utility_ to update your existing files automatically,’ it will be a lot easier for web editors to eliminate non-conforming content and they will be less likely to insist on a quirks mode for SVG.

Comment 35

[Dave Townsend [:mossop]]

*** Bug 326636 has been marked as a duplicate of this bug. ***

Comment 36

[mozilla]

While years have passed, the percentage of SVG content out there missing the namespace declarations seemed to have gone down a lot.

Comment 37

[Robert Longson [:longsonr]]

If you html5 and you don't need namespaces any more.