Error Message Feedback: "valid 1.1"
12 answers - 917 bytes -

I don't find these messages from the new validator to be complete:
This Page Is Valid 1.1!
The uploaded document "animate-elem-08-t.svg" was checked and found to
be valid 1.1. This means that the resource in question identified
itself as "1.1" and that we successfully performed a formal validation
using an SGML or XML Parser (depending on the markup language used).
I mean, 1.1 what? I would prefer that to say
This Page Is Valid SVG Tiny 1.1!
The uploaded document "animate-elem-08-t.svg" was checked and found to
be valid VG Tiny 1.1. This means that the resource in question
identified itself as "SVG Tiny 1.1" and that we successfully performed
a formal validation using an SGML or XML Parser (depending on the markup language used).
The test file was uploaded with the file upload facility and i attached
for convenience.
No.1 | | 927 bytes |
| 
Hello Chris,
Thank you for your report.
Thu, May 26, 2005, Chris Lilley wrote:
I don't find these messages from the new validator to be complete:
This Page Is Valid 1.1!
The uploaded document "animate-elem-08-t.svg" was checked and found to
be valid 1.1. This means that the resource in question identified
itself as "1.1" and that we successfully performed a formal validation
using an SGML or XML Parser (depending on the markup language used).
I mean, 1.1 what?
Bug indeed. After very little testing I noticed that the validator uses
the value of <svg version="_this_" rather than the actual doctype. For
all SVG versions.
I suspect a bug in preparse_doctype(), or, maybe, in HTML::Parser.
I won't be able to work on this until mid-next week. Anyone from the
developers would like to give this a look?
Thanks again, Chris.
No.2 | | 1561 bytes |
| 
Thursday, May 26, 2005, 2:51:03 PM, wrote:
THello Chris,
TThank you for your report.
TThu, May 26, 2005, Chris Lilley wrote:
>
>I don't find these messages from the new validator to be complete:
>
>This Page Is Valid 1.1!
>
>The uploaded document "animate-elem-08-t.svg" was checked and found to
>be valid 1.1. This means that the resource in question identified
>itself as "1.1" and that we successfully performed a formal validation
>using an SGML or XML Parser (depending on the markup language used).
>
>I mean, 1.1 what?
TBug indeed. After very little testing I noticed that the validator
Tuses the value of <svg version="_this_" rather than the actual
Tdoctype. For all SVG versions.
I suggest that it should use a lookup table of namespaces (to
detect that its SVG) and then, having determined that it is SVG, it
could usefully get more info from baseProfile (Tiny, Basic or Full) and
version (1.0, 1.1, 1.2).
SVG 1.1 documents may will have a doctype (but need not). SVG 1.2
documents will never have a doctype (rather, they will never have an
external DTD subset).
TI suspect a bug in preparse_doctype(), or, maybe, in HTML::Parser.
TI won't be able to work on this until mid-next week. Anyone from the
Tdevelopers would like to give this a look?
TThanks again, Chris.
No problem, glad to help. Let me know if you need more info about SVG
versions.
No.3 | | 847 bytes |
| 
* Chris Lilley wrote:
This Page Is Valid 1.1!
The uploaded document "animate-elem-08-t.svg" was checked and found to
be valid 1.1. This means that the resource in question identified
itself as "1.1" and that we successfully performed a formal validation
using an SGML or XML Parser (depending on the markup language used).
>
>I mean, 1.1 what? I would prefer that to say
>
This Page Is Valid SVG Tiny 1.1!
Hi Chris, I checked
and it does not seem to define what it means for a data object to be
"Valid SVG Tiny 1.1". I don't think the Validator should rely on un-
defined terminology, is there a better term we can use? If not, how
about "This document refers to the SVG Tiny 1.1 DTD and is Valid XML
1.0", along with notes about the limited XML support?
No.4 | | 1444 bytes |
| 
Friday, May 27, 2005, 8:32:21 PM, Bjoern wrote:
BH* Chris Lilley wrote:
>This Page Is Valid 1.1!
>>
>The uploaded document "animate-elem-08-t.svg" was checked and found to
>be valid 1.1. This means that the resource in question identified
>itself as "1.1" and that we successfully performed a formal validation
>using an SGML or XML Parser (depending on the markup language used).
>>
>>I mean, 1.1 what? I would prefer that to say
>>
>This Page Is Valid SVG Tiny 1.1!
BHHi Chris, I checked
BH
BHand it does not seem to define what it means for a data object to be
BH"Valid SVG Tiny 1.1". I don't think the Validator should rely on un-
BHdefined terminology, is there a better term we can use?
Not that I can think of. The language is SVG, the baseProfile is Tiny,
and the version is 1.1. Concatenation seems the best way to describe
that - SVG Tiny 1.1.
BHIf not, how
BHabout "This document refers to the SVG Tiny 1.1 DTD and is Valid XML
BH1.0", along with notes about the limited XML support?
I don't see that the limited XML support is relevant to the content. The
same DTD has been used with other processors that do not note any
particular limitations in their XML support.
Could you define "refers to" ?
No.5 | | 1885 bytes |
| 
* Chris Lilley wrote:
I suggest that it should use a lookup table of namespaces (to
>detect that its SVG) and then, having determined that it is SVG, it
>could usefully get more info from baseProfile (Tiny, Basic or Full) and
>version (1.0, 1.1, 1.2).
We currently dispatch based on the media type and user settings, trying
to sniff for content types is widely considered harmful and would not
work for e.g. application/xml with
<svg version = "1.1"
baseProfile = "tiny"
xmlns = "http://www.w3.org/2000/svg"
xsl:version = "1.0"
xmlns:xsl = "" />
as that is a XSLT 1.0 document and should be processed per the XSLT 1.0
rules, not per SVG rules. So we would need to sniff and apply additional
heuristics to determine the type. And even if we do that, the SVG specs
contradict each other for the version attribute, in SVG Tiny 1.1
<svg baseProfile = "tiny"
xmlns = "http://www.w3.org/2000/svg" />
implementations must process the document as if it had version="1.1"
and in SVG Tiny 1.2 they apparently must process the document as if it
had version="1.2" (SVG Tiny 1.1 states that SVG 1.1 states it must be
set to 1.1 but that's just a SHULD in SVG 1.1). Same for the base-
Profile attribute, it's optional and defaults to "none", so it's not
clear to me how to determine the exact conformance criteria that must
be checked for for any given image/svg+xml input either. And hence how
to make positive or negative statements about the document relative
to these criteria.
We could perhaps make up some 80/20 rules that generally work, but we
would likely have to make changes to that e.g. if SVG 1.3 comes out
which would mean the Validator gives different results over time which
is highly undesirable.
No.6 | | 1419 bytes |
| 
* Chris Lilley wrote:
>Not that I can think of. The language is SVG, the baseProfile is Tiny,
>and the version is 1.1. Concatenation seems the best way to describe
>that - SVG Tiny 1.1.
Consider
<svg version="1.1" baseProfile="tiny"
xmlns="http://www.w3.org/2000/svg">
<path d="M275,175 v-150 a150,150 0 0,0 -150,150 z"
fill="yellow" stroke="blue" stroke-width="5" />
</svg>
This does not seem to be a conforming SVG Tiny 1.1 document
fragment, is it a "Valid SVG Tiny 1.1" document? Without a
definition that's difficult to tell. And if it is, we would
likely confuse Validator users.
>I don't see that the limited XML support is relevant to the content.
It's not, but it's relevant to what statements the Validator
makes about the content, you could have
<?xml hello world?>
<svg version="1.1" baseProfile="tiny"
xmlns="http://www.w3.org/2000/svg" />
which the Validator currently considers "valid" even though
it is not even well-formed. To avoid confusion about this,
the Validator always notes its limited XML support in the
result.
>Could you define "refers to" ?
A document refers to a specific DTD by using a matching FPI
for the external subset.
No.7 | | 1436 bytes |
| 
Friday, May 27, 2005, 9:31:52 PM, Bjoern wrote:
BH* Chris Lilley wrote:
>I suggest that it should use a lookup table of namespaces (to
>>detect that its SVG) and then, having determined that it is SVG, it
>>could usefully get more info from baseProfile (Tiny, Basic or Full) and
>>version (1.0, 1.1, 1.2).
BHWe currently dispatch based on the media type and user settings, trying
BHto sniff for content types is widely considered harmful
, please.
Reading the namespace is not 'sniffing'. Its normal and expected
behaviour for XML processors.
BHand would not
BHwork for e.g. application/xml with
BH<svg version = "1.1"
BHbaseProfile = "tiny"
BHxmlns = "http://www.w3.org/2000/svg"
BHxsl:version = "1.0"
BHxmlns:xsl = "" />
BHas that is a XSLT 1.0 document and should be processed per the XSLT 1.0
BHrules, not per SVG rules.
Actually I was thinking of the XML 1.0 + XML Namespaces rules. The above
instance is, of course, invalid due to the undeclared xsl:version
attribute.
BHSo we would need to sniff and apply additional
BHheuristics to determine the type.
?
Really not sure where you are going with that. I mean, reading the
namespace declaration to find out what namespace it is seems, uh, not
too big a stretch.
No.8 | | 801 bytes |
| 
May 27, 2005, at 19:31, Chris Lilley wrote:
I suggest that it should use a lookup table of namespaces (to
detect that its SVG) and then, having determined that it is SVG, it
could usefully get more info from baseProfile (Tiny, Basic or Full) and
version (1.0, 1.1, 1.2).
What if the DTD does not match?
<!DCTYPE svg "BogoDTD" "http://example.com/bogo.dtd">
<svg version = "1.1"
baseProfile = "tiny"
xmlns = "http://www.w3.org/2000/svg">
<bogo/>
</svg>
The basic problem is of course that DTD validation does not answer the
question "Does document D conform to grammar G?" but answers the
question "Does document D conform the grammar it happens to declare?"
(RELAX NG validation would answer the first question.)
No.9 | | 3106 bytes |
| 
Saturday, May 28, 2005, 1:38:24 PM, Henri wrote:
HSMay 27, 2005, at 19:31, Chris Lilley wrote:
>I suggest that it should use a lookup table of namespaces (to
>detect that its SVG) and then, having determined that it is SVG, it
>could usefully get more info from baseProfile (Tiny, Basic or Full) and
>version (1.0, 1.1, 1.2).
HSWhat if the DTD does not match?
HS<!DCTYPE svg "BogoDTD" "http://example.com/bogo.dtd">
HS<svg version = "1.1"
HSbaseProfile = "tiny"
HSxmlns = "http://www.w3.org/2000/svg">
HS<bogo/>
HS</svg>
Well then it wouldn't be valid :) as the DTD validator would report.
More interesting are these cases
<!DCTYPE svg "-//W3C//DTD SVG 1.1//EN"
"">
<svg version = "1.1"
baseProfile = "tiny"
xmlns = "http://www.w3.org/2000/svg">
<bogo/>
</svg>
An SVG Tiny 1.1 file, which references the SVG Full 1.1 DTD. Tiny is a
subset of Full, so all valid Tiny 1.1 content is also valid Full 1.1
content.
<!DCTYPE svg "-//W3C//DTD SVG 1.1 Tiny//EN"
"http://example.com/bogo.dtd">
<svg version = "1.1"
baseProfile = "tiny"
xmlns = "http://www.w3.org/2000/svg">
<bogo/>
</svg>
Maybe bogo is a local copy of the DTD. That's allowed.
HSThe basic problem is of course that DTD validation does not answer the
HSquestion "Does document D conform to grammar G?" but answers the
HSquestion "Does document D conform the grammar it happens to declare?"
Right. The point is, how do you get the name of that grammar. I mean,
people understand 'Valid XHTML 1.1" a lot more easily than "Valid
"-//W3C//DTD XHTML 1.1//EN" subject to certain limitations".
Looking at the name of the grammar, you can look at the namespace (which
is authoritative) or, as Bjoern seems to suggest, look at the FPI.
Looking at, for example,
#s_doctype
I don't see any language, normative or informative, that states that
"-//W3C//DTD XHTML 1.1//EN"
is the formal public identifier.
#a_xhtml11_dtd
is normative, but the information about the FPI is in a comment in the
DTD. Usefully however there is an catalog file
#a_xhtml11_catalog
Similarly
#DTD.1
is normative, but
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES SVG 1.1 Modular Framework//EN"
SYSTEM ""
is contained in a comment in the DTD.
(Aha!) Bjoern, are you asking for the SVG specifications that use DTDs
to include an catalog file? Do you believe that would make the FPI
normative?
If so, could you explain what is non-normative about
#Namespace
HS(RELAX NG validation would answer the first question.)
Yes it would. I would be very interested to see a RelaxNG validator
option. Note that in RelaxNG (and in W3C XML Schema) the pointer to the
schema is not contained, necessarily, in the document instance.
No.10 | | 1706 bytes |
| 
May 30, 2005, at 16:08, Chris Lilley wrote:
Saturday, May 28, 2005, 1:38:24 PM, Henri wrote:
HSMay 27, 2005, at 19:31, Chris Lilley wrote:
I suggest that it should use a lookup table of namespaces (to
detect that its SVG) and then, having determined that it is SVG, it
could usefully get more info from baseProfile (Tiny, Basic or Full)
and
version (1.0, 1.1, 1.2).
HSWhat if the DTD does not match?
HS<!DCTYPE svg "BogoDTD" "http://example.com/bogo.dtd">
HS<svg version = "1.1"
HSbaseProfile = "tiny"
HSxmlns = "http://www.w3.org/2000/svg">
HS<bogo/>
HS</svg>
Well then it wouldn't be valid :) as the DTD validator would report.
How do you know bogo.dtd does not make that valid?
HSThe basic problem is of course that DTD validation does not answer
the
HSquestion "Does document D conform to grammar G?" but answers the
HSquestion "Does document D conform the grammar it happens to
declare?"
Right. The point is, how do you get the name of that grammar.
By focusing on the first question and asking the user to select the
schema to validate against.
HS(RELAX NG validation would answer the first question.)
Yes it would. I would be very interested to see a RelaxNG validator
option.
schema=http%3A%2F%2Fwww.w3.org%2FGraphics%2FSVG%2F 1.2%2Frng%2FTiny
-1.2%2FTiny-1.2.rng&laxtype=yes
Note that in RelaxNG (and in W3C XML Schema) the pointer to the
schema is not contained, necessarily, in the document instance.
I consider that a desirable feature of RELAX NG. I think doctype and
schemaLocation are design bugs.
No.11 | | 3015 bytes |
| 
Monday, May 30, 2005, 4:07:46 PM, Henri wrote:
HSMay 30, 2005, at 16:08, Chris Lilley wrote:
>Saturday, May 28, 2005, 1:38:24 PM, Henri wrote:
>>
>HSMay 27, 2005, at 19:31, Chris Lilley wrote:
>>
I suggest that it should use a lookup table of namespaces (to
detect that its SVG) and then, having determined that it is SVG, it
could usefully get more info from baseProfile (Tiny, Basic or Full)
and
version (1.0, 1.1, 1.2).
>>
>HSWhat if the DTD does not match?
>>
>HS<!DCTYPE svg "BogoDTD" "http://example.com/bogo.dtd">
>HS<svg version = "1.1"
>HSbaseProfile = "tiny"
>HSxmlns = "http://www.w3.org/2000/svg">
>HS<bogo/>
>HS</svg>
>>
>Well then it wouldn't be valid :) as the DTD validator would report.
HSHow do you know bogo.dtd does not make that valid?
You don't, except by trying it. Any more than you know that
<?xml version="1.0" encoding="UTF-8"?>
<!DCTYPE svg
PUBLIC "-//W3C//DTD SVG 1.1 Tiny//EN"
""[
<!ENTITY % SVG.svg.extra.content "| bogo" >
<!ELEMENT bogo EMPTY >
]>
<svg version = "1.1"
baseProfile = "tiny"
xmlns = "http://www.w3.org/2000/svg">
<bogo/>
</svg>
is valid, except by trying. (Its valid to the DTD, but is not conformant
because the bogo element was put in the SVG namespace).
>HSThe basic problem is of course that DTD validation does not answer
>the
>HSquestion "Does document D conform to grammar G?" but answers the
>HSquestion "Does document D conform the grammar it happens to
>declare?"
>>
>Right. The point is, how do you get the name of that grammar.
HSBy focusing on the first question and asking the user to select the
HSschema to validate against.
K, fair enough.
>HS(RELAX NG validation would answer the first question.)
>>
>Yes it would. I would be very interested to see a RelaxNG validator
>option.
HS
HSschema=http%3A%2F%2Fwww.w3.org%2FGraphics%2FSVG% 2F1.2%2Frng%2FTiny
HS-1.2%2FTiny-1.2.rng&laxtype=yes
Thanks! What does laxtype=yes do?
>Note that in RelaxNG (and in W3C XML Schema) the pointer to the
>schema is not contained, necessarily, in the document instance.
HSI consider that a desirable feature of RELAX NG. I think doctype and
HSschemaLocation are design bugs.
I agree with that, especially since I have become more convinced of the
utility of validating to different schemas for different purposes.
No.12 | | 1559 bytes |
| 
May 30, 2005, at 18:17, Chris Lilley wrote:
Monday, May 30, 2005, 4:07:46 PM, Henri wrote:
HSMay 30, 2005, at 16:08, Chris Lilley wrote:
Saturday, May 28, 2005, 1:38:24 PM, Henri wrote:
HSMay 27, 2005, at 19:31, Chris Lilley wrote:
I suggest that it should use a lookup table of namespaces (to
detect that its SVG) and then, having determined that it is SVG, it
could usefully get more info from baseProfile (Tiny, Basic or Full)
and
version (1.0, 1.1, 1.2).
HSWhat if the DTD does not match?
HS<!DCTYPE svg "BogoDTD" "http://example.com/bogo.dtd">
HS<svg version = "1.1"
HSbaseProfile = "tiny"
HSxmlns = "http://www.w3.org/2000/svg">
HS<bogo/>
HS</svg>
Well then it wouldn't be valid :) as the DTD validator would report.
HSHow do you know bogo.dtd does not make that valid?
You don't, except by trying it.
Right. My point was that it would be misleading to say it is valid SVG
Tiny 1.1 if the validity was based on the bogo DTD (assuming the DTD
made it valid) but the name and version on the root element.
HS
HSschema=http%3A%2F%2Fwww.w3.org%2FGraphics%2FSVG% 2F1.2%2Frng%2FTiny
HS-1.2%2FTiny-1.2.rng&laxtype=yes
Thanks! What does laxtype=yes do?
It makes the entity resolver not reject some common non-XML types
(text/plain, text/html and text/xsl). Also, it turns off the
enforcement of the US-ASCII default for text/* types.
The SVG Tiny 1.2 schema is served as text/plain.