Re: SVG 1.2 Comment: Media type registration conformance and XML namespaces

On Tuesday, November 2, 2004, 2:05:31 AM, L. wrote:


LDB> The media type registration [1] for image/svg+xml should be changed so
LDB> that a conformant image/svg+xml processor must not treat XML elements
LDB> that are in no namespace as though they were in the SVG namespace.

I don't see that such a statement belongs in the media type registration
template. I agree that the statement needs to be in the spec.

LDB> Omission of namespaces seems to be a common authoring mistake in SVG on
LDB> the Web, for example [2], which suggests that this is a common mistake
LDB> in existing SVG implementations.  Such documents are not conformant SVG
LDB> documents because of:
LDB>  * the "an SVG namespace declaration must be provided" requirement in [3], and
LDB>  * because of the validity test in [5] (which would attempt to validate
LDB>    a document with no root element, since no elements are in the SVG
LDB>    namespace).

Yes.

LDB> The SVG 1.1 specification does not define error handling for such
LDB> documents.  This is perfectly reasonable, since describing the behavior
LDB> of elements outside of the SVG namespace is out of scope of the SVG
LDB> specification.

The SVG 1.1 spec does say what to do with elements outside the SVG
namespace;  SVG 1.2 does not alter that:

http://www.w3.org/TR/SVG11/conform.html#ConformingSVGDocuments
G.2 Conforming SVG Document Fragments

Note that the result of applying that on the common authoring mistake is
an empty document.


LDB>  However, now that the SVG specification contains a media
LDB> type registration, that media type registration should define how to
LDB> handle documents that would not otherwise be considered SVG when sent
LDB> using the registered media type.

(I believe the spec already defines this case).

LDB> I don't have strong opinions on *how* the registration should forbid
LDB> treating the no-namespace elements as SVG.  One reasonable way would be
LDB> stating that a conformant image/svg+xml processor must abort processing
LDB> of any document sent as image/svg+xml unless the root element of that
LDB> document is in the "http://www.w3.org/2000/svg" namespace.

No, that is undesirable. We have taken care in the SVG spec not to make
that assumption; we use the phrase 'root most svg element' and 'svg
document fragment' rather than 'root element' and 'document', for
example.

LDB>   I believe
LDB> this requirement would be sufficient to bootstrap the error-handling
LDB> requirements for unknown elements ([6] and [7]).

LDB> -David

LDB> [1] http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html

LDB> [2]
LDB> http://www.w3.org/Consortium/Offices/Presentations/svgs/World.svg
LDB>     and the external resources it references:
LDB>      
LDB> http://www.w3.org/Consortium/Offices/Presentations/svgs/WorldAS.svgz
LDB>      
LDB> http://www.w3.org/Consortium/Offices/Presentations/svgs/WorldEU.svgz
LDB>      
LDB> http://www.w3.org/Consortium/Offices/Presentations/svgs/WorldUS.svgz
LDB>     These four files currently use SVG elements with no namespace
LDB>     prefixes but have no xmlns attribute making the SVG namespace the
LDB>     default on the root element and have no DOCTYPE declaration that
LDB>     would introduce such an attribute.

LDB> [3]
LDB> http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#NewDocumentOverview
LDB>     (Although, for documents that have a DOCTYPE declaration, such as
LDB>     [4], it is unclear whether this requirement means that the xmlns
LDB>     declaration must also be explicitly provided.)

LDB> [4] http://www.w3.org/2002/05/memberGraph.svgz

LDB> [5]
LDB> http://www.w3.org/TR/2003/REC-SVG11-20030114/conform.html#ConformingSVGDocuments

LDB> [6]
LDB> http://www.w3.org/TR/2003/REC-SVG11-20030114/extend.html#PrivateData

LDB> [7]
LDB> http://www.w3.org/TR/2003/REC-SVG11-20030114/implnote.html#ErrorProcessing





-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Tuesday, 2 November 2004 16:22:25 UTC