Re: Simple suggestion

I agree; navigation is a good idea; a site map is also a good idea.

Regards,

Rob

Rob Davis, P.E.
Software QA/Verification/Validation/Test Engineer
Web site: http://www.robdavispe.com

[VE][108] New Error Message Suggestion

Re: [VE][108] New Error Message Suggestion

Dru,

I think the error tht you are talking about is generated by onsgmls. XML
is case-sensitive. All the attributes are defined in a DTD. onsgmls
validates against a DTD, and if the attribute isn't a valid attribute in
the DTD (case-sensitive), onsgmls will produce the err msg. onsgmls
doesn't care that only the case of an attribute in wrong.

In Peace,
Saqib Ali
---------
http://validate.sf.net <--- XHTML/HTML/DocBook Validator

On Sun, 2 Nov 2003, Dru Sellers wrote:

> This particular error seems to be of a String Format type. Instead of
> saying that this document type does not support this attribute it would
> be more informative to say that the attribute is not formatted correctly
> and that all attributes should be cast in lower case.
>
>
> <input id="v" onblur="" />
> <input id="d" onBlur="" />
>
> Thanks for the great tools!!!
> Dru Sellers
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.532 / Virus Database: 326 - Release Date: 10/27/2003
>
>

cgi-bin access from "18.29.1.50"

Today I recieved the following error logfile:

[Mon Nov  3 09:35:01 2003] [error] [client 18.29.1.50] script not found or
unable to stat:
/is/htdocs/38751/www.bruechner.de/cgi-bin/passwortschutz.pl
[Mon Nov  3 09:36:09 2003] [error] [client 18.29.1.50] script not found or
unable to stat:
/is/htdocs/38751/www.bruechner.de/cgi-bin/passwortschutz.pl
[Mon Nov  3 09:39:30 2003] [error] [client 18.29.1.50] client denied by
server configuration:
/is/htdocs/38751/www.bruechner.de/cgi-bin/htaccess.pl
[Mon Nov  3 09:39:31 2003] [error] [client 18.29.1.50] client denied by
server configuration:
/is/htdocs/38751/www.bruechner.de/cgi-bin/htaccess.pl

The IP 18.29.1.50 is the same as MarkUp Validation Service, how could this
be?

Simon

Empty <script> bug (XHTML documents)

I have noticed that XHTML documents are passed as valid even when they 
contain empty <script> elements. For example,

  <script src="js/whatever.js"/>

is not considered to infringe the DTD, which specifies that <script> 
contains PCDATA.

Is this a bug in the W3C Validator?
Rick

[ref: XHTML1.0: 
http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict]

--
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.

Re: Empty <script> bug (XHTML documents)

>   <script src="js/whatever.js"/>
this is valid

Saqib Ali
---------
http://validate.sf.net <--- XHTML/HTML/DocBook Validator

Re: Empty <script> bug (XHTML documents)

On Mon, 3 Nov 2003, Beton, Richard wrote:

> I have noticed that XHTML documents are passed as valid even when they
> contain empty <script> elements. For example,
>
>   <script src="js/whatever.js"/>

Why would that not be valid? By XML rules, it is equivalent to
<script src="js/whatever.js"></script>

"Empty-element tags may be used for any element which has no content,
whether or not it is declared using the keyword EMPTY. For
interoperability, the empty-element tag should be used, and should only be
used, for elements which are declared EMPTY."
  http://www.w3.org/TR/REC-xml#sec-starttags

(The empty-element tag adhockery is a constant source of confusion; for a
treatise, see http://www.cs.tut.fi/~jkorpela/html/empty.html )

--

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Update to MathML DTD

I have updated the MathML 2 DTD available from 

http://www.w3.org/Math/DTD

This update is generated from the XML sources used to generate the
recent MathML 2 second edition recommendation, and so brings the dtd
into line with chapter 6 and appendix A of that Recommendation.

To update off line copies, the gzipped tar file,
  http://www.w3.org/Math/DTD/mathml2.tgz 
should have all the necessary files

At the end of this message is a diff of the xhtml+mathml dtd,
differences to the mathml dtd, and the individual entity files
will clearly be appropriate subsets of this.

The documentation at
  http://www.w3.org/Math/characters
has been similarly regenerated.

David

Index: xhtml-math11-f.dtd
===================================================================
RCS file: /w3ccvs/WWW/Math/DTD/mathml2/xhtml-math11-f.dtd,v
retrieving revision 1.15
diff -r1.15 xhtml-math11-f.dtd
5468,5472d5467
< <![%MathMLstrict;[
<   <!ATTLIST %menclose.qname;
<       %MATHML.Common.attrib;
<       notation ( longdiv | actuarial | radical ) 'longdiv' >
< ]]>
5510a5506,5507
>       %att-height;		
>       %att-depth;		
7562c7559
< <!ENTITY nsubE            "&#x02AC5;&#x0338;" ><!--/nsubseteqq N: not subset, dbl eq -->
---
> <!ENTITY nsubE            "&#x02AC5;&#x00338;" ><!--/nsubseteqq N: not subset, dbl eq -->
7565c7562
< <!ENTITY nsupE            "&#x02AC6;&#x0338;" ><!--/nsupseteqq N: not superset, dbl eq -->
---
> <!ENTITY nsupE            "&#x02AC6;&#x00338;" ><!--/nsupseteqq N: not superset, dbl eq -->
7640a7638
> <!ENTITY bbrktbrk         "&#x023B6;" ><!--bottom above top square bracket -->
7672a7671
> <!ENTITY trpezium         "&#x0FFFD;" ><!--trapezium -->
7831a7831
> <!ENTITY sfrown           "&#x02322;" ><!--/smallfrown R: small down curve -->
7845a7846
> <!ENTITY ssmile           "&#x02323;" ><!--/smallsmile R: small up curve -->
7859c7860
< <!ENTITY suphsol          "&#x02283;&#x00338;" ><!--superset, solidus -->
---
> <!ENTITY suphsol          "&#x02283;&#x0002F;" ><!--superset, solidus -->
7867a7869
> <!ENTITY thksim           "&#x0223C;" ><!--/thicksim R: thick similar -->
7914,7915c7916,7917
< <!ENTITY epsi             "&#x003B5;" ><!--/straightepsilon, small epsilon, Greek -->
< <!ENTITY epsiv            "&#x0025B;" ><!--/varepsilon -->
---
> <!ENTITY epsi             "&#x003F5;" ><!--/straightepsilon, small epsilon, Greek -->
> <!ENTITY epsiv            "&#x003B5;" ><!--/varepsilon -->
8192,8193d8193
< <!ENTITY % plane1D  "&#38;#38;#x1D">
< 
8230c8230
< <!ENTITY DotDot           "&#x020DC;" ><!--four dots above -->
---
> <!ENTITY DotDot           " &#x020DC;" ><!--four dots above -->
8233a8234
> <!ENTITY elinters         "&#x0FFFD;" ><!--electrical intersection -->
8238a8240
> <!ENTITY fltns            "&#x025B1;" ><!--flatness -->
8246c8248
< <!ENTITY imped            "%plane1D;543;" ><!--impedance -->
---
> <!ENTITY imped            "&#x001B5;" ><!--impedance -->
8247a8250
> <!ENTITY infintie         "&#x029DD;" ><!--tie, infinity -->
8279a8283
> <!ENTITY notinE           "&#x022F9;&#x00338;" ><!--negated set membership, two horizontal strokes -->
8331a8336
> <!ENTITY strns            "&#x000AF;" ><!--straightness -->
8336c8341
< <!ENTITY tdot             "&#x020DB;" ><!--three dots above -->
---
> <!ENTITY tdot             " &#x020DB;" ><!--three dots above -->
9082c9087
< <!ENTITY DownBreve        "&#x00311;" ><!--breve, inverted (non-spacing) -->
---
> <!ENTITY DownBreve        " &#x00311;" ><!--breve, inverted (non-spacing) -->
9164c9169
< <!ENTITY UnderBar         "&#x00332;" ><!--combining low line -->
---
> <!ENTITY UnderBar         " &#x00332;" ><!--combining low line -->
9547c9552
< <!ENTITY nsubseteqq       "&#x02AC5;&#x0338;" ><!--alias ISOAMSN nsubE -->
---
> <!ENTITY nsubseteqq       "&#x02AC5;&#x00338;" ><!--alias ISOAMSN nsubE -->
9552c9557
< <!ENTITY nsupseteqq       "&#x02AC6;&#x0338;" ><!--alias ISOAMSN nsupE -->
---
> <!ENTITY nsupseteqq       "&#x02AC6;&#x00338;" ><!--alias ISOAMSN nsupE -->
9650c9655
< <!ENTITY straightepsilon  "&#x003B5;" ><!--alias ISOGRK3 epsi -->
---
> <!ENTITY straightepsilon  "&#x003F5;" ><!--alias ISOGRK3 epsi -->
9700c9705
< <!ENTITY TripleDot        "&#x020DB;" ><!--alias ISOTECH tdot -->
---
> <!ENTITY TripleDot        " &#x020DB;" ><!--alias ISOTECH tdot -->
9723c9728
< <!ENTITY varepsilon       "&#x0025B;" ><!--alias ISOGRK3 epsiv -->
---
> <!ENTITY varepsilon       "&#x003B5;" ><!--alias ISOGRK3 epsiv -->
9799c9804
<        Pepping on www-math list) 2003-05-22		
---
>           Pepping on www-math list) 2003-05-22		
9802c9807,9809
<        Pepping on www-math list) 2003-05-22		
---
>           Pepping on www-math list) 2003-05-22		
>           David Carlisle		
>        Removed restricted menclose notation checking from MathMLstrict 2003-09-08		
9821,9822d9827
< 
< 

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Validator and XHTML 1.1

Dear all, 

as of today, the validator is unable to validate XHTML 1.1 files created
with Amaya. Is there a plan to fix this? 

Furthermore, to link stylesheets, Amaya uses:

<link xmlns:xlink="http://www.w3.org/1999/xlink"
  href="/TR/W3C-WD.css" rel="stylesheet"
	type="text/css" />

The validator response that this is invalid. Are there plans to fix
this? Are there plans to synchronize with the Amaya-folks so that
Amaya produces valid results or that the validator can evaluate output
from Amaya?

Best, 

Rigo

Re: Validator and XHTML 1.1

On Nov 5, 2003, at 12:55 AM, Rigo Wenning wrote:
> as of today, the validator is unable to validate XHTML 1.1 files 
> created
> with Amaya. Is there a plan to fix this?
>
> Furthermore, to link stylesheets, Amaya uses:
>
> <link xmlns:xlink="http://www.w3.org/1999/xlink"
>   href="/TR/W3C-WD.css" rel="stylesheet"
> 	type="text/css" />
>
> The validator response that this is invalid.

For such reports, a URI with a sample document helps. Validity is very 
dependent on context (e.g I have no way of guessing what makes the 
validator "unable to validate XHTML 1.1 files created with Amaya" when 
it can validate other XHTML1.1 files without trouble...

>  Are there plans to fix this?

I believe Irene's mail answers this(?).

>  Are there plans to synchronize with the Amaya-folks so that
> Amaya produces valid results or that the validator can evaluate output
> from Amaya?

Not sure I understand...

If Amaya produces invalid content it needs to be fixed. If the 
validator gives wrong validation results it needs to be fixed. As far 
as I can tell this does not take "Synchronization" between amaya and 
the validator. Amaya uses technology which the validator validates: the 
coordination happens with the groups that produce these technologies.

Of course Amaya folks are always welcome to discuss with the validator 
folks when interpretations of suchandsuch specification differs, and 
welcome to use the validator as other authoring tools do or plan to do.

--

-- 
olivier