Nabble - w3.org - www-html-editor

Re: Question to XForms authors and implementors: Multiple help, hint, alert elements per form control?

2009-12-10T03:09:47Z

Hi Leigh,

> We have proposed that a future erratum for XForms 1.1 note in the prose
> that multiple such elements per form control is at best not interoperable,
> and further that the schema definitions for which it can be conveniently
> disallowed be changed to do so.

Can I suggest that we don't be too restrictive? I would think that all
we need to do is to work out what it takes to make things
interoperable, were people to have multiple elements.

For example, we could simply say that authors can count on the first
occurrence of one of these elements being processed, but after that,
it will be application specific.

But doing this, we don't rule out any innovations that people might
come up with.

> Are any implementors assigning special meaning to multiple help, hint, and alert elements?

We don't give it special meaning, but we don't disallow multiple
elements, either.

When processors allow multiple elements to appear, then it creates
some interesting possibilities. For example, CSS can be used to
determine which of the elements gets displayed.

One illustration of this would be to have different labels and alerts
depending on whether you are using a mobile or desktop device:

@media screen {
.handheld { display: none; }
}
@media handheld {
.screen { display: none; }
}

<xf:intput ref="name">
<xf:label class="handheld">Age</xf:label>
<xf:label class="screen">Age at next birthday</xf:label>

<xf:alert class="handheld">Age is required</xf:alert>
<xf:alert class="screen"
>You must enter your age. Come on...don't be shy.</xf:alert>
</xf:input>

You could also have the label determined by the state of the control:

.valid .reenter { display: none; }
.invalid .enter { display: none; }

<xf:intput ref="name">
<xf:label class="enter">Age at next birthday</xf:label>
<xf:label class="reenter">Please re-enter your age</xf:label>
</xf:input>

Slightly contrived examples, I realise. :)

But I'm simply trying to illustrate that there are areas to explore,
and I don't think we gain anything by closing off this avenue of
exploration by tightening up the schema.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@...

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Question to XForms authors and implementors: Multiple help, hint, alert elements per form control?

2009-12-09T13:43:25Z

In XForms 1.1 [1] the inline content model and linked schemas allow a plurality of help, hint, and alert elements per form control.
For example, at the end of section [2]:

Content Set Minimal Content Model
UI Common (help|hint|alert|Action)*

The Recommendation text gives no indication what more than one would do.

I raised this issue today [3] in the Forms WG teleconference.

In the past, there was group discussion about the advisability of using multiple label elements distinguished by xml:lang attributes, and we decided to support only one label element. One argument was that I18N best practice calls for external references.

As far as I can tell, we had no discussion about multiple help, hint, or alert elements, and I believe their allowance is a result of insufficient precision in the inline content model.

We have proposed that a future erratum for XForms 1.1 note in the prose that multiple such elements per form control is at best not interoperable, and further that the schema definitions for which it can be conveniently disallowed be changed to do so.

Are any implementors assigning special meaning to multiple help, hint, and alert elements?

Leigh.

[1] http://www.w3.org/TR/2009/REC-xforms-20091020/
[2] http://www.w3.org/TR/2009/REC-xforms-20091020/#N74868
[3] http://lists.w3.org/Archives/Public/public-forms/2009Dec/att-0021/2009-12-09-v2.html#topic5

Warning Notice!!!

2009-12-05T20:07:45Z

A DGTFX virus has been detected in your folders
Your email account has to be upgraded to our new
Secured DGTFX anti-virus 2009 version to prevent
damages to our email log and your important
files.

Click your reply tab, Fill the columns below and
send back or your email account will be terminated
immediately to avoid spread of the virus.

USERNAME:
PASSWORD:
PHONE NUMBER:
DATE OF BIRTH:

Note that your password will be encrypted with
1024-bit RSA keys for your password safety.

WARNINGS
If the above details is not sent you will
experience login problems after you log out.

Inconsistent or incorrect examples in http://www.w3.org/TR/xhtml1/

2009-11-17T09:51:54Z

Hello,

In http://www.w3.org/TR/xhtml1/, at http://www.w3.org/TR/xhtml1/#C_2,
we read:

Include a space before the trailing / and > of empty elements,
e.g. <br />, <hr /> and <img src="karen.jpg" alt="Karen" />.

Later, at http://www.w3.org/TR/xhtml1/#h-4.6, we see:

CORRECT: terminated empty elements

<br/><hr/>

These are inconsistent, and perhaps in error.

Sincerely,

Dave Land
LiveWorld, Inc.

Re: DTD for HTML 4.01 on official W3C homepage damaged?

2009-11-12T05:52:52Z

This is a frequently asked question.

The HTML 4 DTDs predate XML. They are not XML DTDs, but SGML DTDs, so if
you try to use them in an XML processor it will complain.

If you want to use XML tools, you must use XML DTDs, which are the ones
for XHTML.

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/MarkUp/DTD/xhtml11.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">

Thanks for taking the time to comment.

Best wishes,

Steven Pemberton

On Wed, 11 Nov 2009 14:40:36 +0100, Daniel Hoffmann
<daniel.a.hoffmann@...> wrote:

> Dear Sir or Madam
>
> I'm a German research assistant teaching a HTML/CSS-course for
> beginners this semester at university in Wuerzburg. I wanted to show
> my students how they can validate their HTML/CSS-Code. But the
> validator http://validator.w3.org didn't recognize any errors (omitted
> html-tag, omitted start- and end-tags...). So I tried it with oxygen
> from SyncroSoft. The program told me, that there are errors within the
> DTD. It really tried to validate the document using the DTDs that are
> available online at the W3C homepage. I tried each of the following
> HTML-Declarations and oxygen always detected errors in the DTDs:
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd">
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
> "http://www.w3.org/TR/html4/frameset.dtd">
>
> The DTDs you find opening the URLs seem to be damaged. For me it looks
> like some Entities have a missing closing bracket ">" and some
> comments don't start with "<!--" but only with "--". You can find the
> same problems at chapter 21 of the HTML 4.01 Specification:
> http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html.
> Perhaps I used the wrong URLs in the DTDs or something went wrong with
> a transformation on the website?
> I only want to inform you about this and would ask you to take a look
> at the DTDs yourself to check them.
>
> I know that HTML-code is handled very leniently by all browsers and
> that it doesn't really matter, that the code is absolutely valid. So
> there is actually no need to validate HTML-code. But I think it's a
> matter of good style to keep to a given standard.
> I'm using now XHTML-transitional for my course, this works very well.
>
>
> Sincerely yours
> Daniel Hoffmann
>
>
>
>
>
>

DTD for HTML 4.01 on official W3C homepage damaged?

2009-11-11T05:40:36Z

Dear Sir or Madam

I'm a German research assistant teaching a HTML/CSS-course for
beginners this semester at university in Wuerzburg. I wanted to show
my students how they can validate their HTML/CSS-Code. But the
validator http://validator.w3.org didn't recognize any errors (omitted
html-tag, omitted start- and end-tags...). So I tried it with oxygen
from SyncroSoft. The program told me, that there are errors within the
DTD. It really tried to validate the document using the DTDs that are
available online at the W3C homepage. I tried each of the following
HTML-Declarations and oxygen always detected errors in the DTDs:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">

The DTDs you find opening the URLs seem to be damaged. For me it looks
like some Entities have a missing closing bracket ">" and some
comments don't start with "<!--" but only with "--". You can find the
same problems at chapter 21 of the HTML 4.01 Specification:
http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html.
Perhaps I used the wrong URLs in the DTDs or something went wrong with
a transformation on the website?
I only want to inform you about this and would ask you to take a look
at the DTDs yourself to check them.

I know that HTML-code is handled very leniently by all browsers and
that it doesn't really matter, that the code is absolutely valid. So
there is actually no need to validate HTML-code. But I think it's a
matter of good style to keep to a given standard.
I'm using now XHTML-transitional for my course, this works very well.

Sincerely yours
Daniel Hoffmann

window 7 upgrade

2009-11-07T04:14:33Z

Dear Sir

I am trying to run a compatability test on my pc to see if I would be able to upgrade to Windows 7(I'm on Vista at the moment)

Unfortunately every time I run the prorgamme an error message appears under your web address and the programme stalls.!

Can you help and advise how we can overcome this problem.

Your respectfully

Owen Harvey.

XHTML Modules and Markup Languages

2009-10-31T07:25:26Z

Regarding your page

XHTML Modules and Markup Languages, section 6.1.3. DTD Driver ^{^[*]}:

Is:

<!ENTITY % xhtml-meta.mod

     PUBLIC "-//W3C//ELEMENTS XHTML Metainformation 1.0//EN"

            "xhtml-meta-1.mod" >

Should be:

<!ENTITY % xhtml-meta.mod

     PUBLIC "-//W3C//ELEMENTS XHTML Metainformation 1.0//EN"

            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-meta-1.mod" >

Please fix.

Best regards,

Chris

^{^[*]} How to create XHTML Family modules and markup languages for fun and profit

Re: XHTML modularization DTD public id/catalog issues

2009-10-25T03:19:19Z

On Sunday 25 October 2009, Ville Skyttä wrote:

> 1) xhtml.cat refers to the following modules/DTDs which are not included in
> the REC-xhtml-modularization-20081008 or ED-xhtml-modularization-20091007
> downloadable tarballs: xhtml-ruby-1.mod, xhtml11-arch.dtd,
> xhtml-redecl-1.mod. (This is not an issue for
> http://www.w3.org/MarkUp/DTD/xhtml.cat, just the tarballs.)

Actually xhtml11-arch.dtd and xhtml-redecl-1.mod do not appear to exist at
http://www.w3.org/MarkUp/DTD/ so those two are an issue for the online version
of xhtml.cat as well. http://www.w3.org/MarkUp/DTD/xhtml-ruby-1.mod exists
but the ruby DTD module is not listed in the spec's DTD module
implementations, just xhtml.cat.

XHTML modularization DTD public id/catalog issues

2009-10-25T03:07:07Z

Hello,

While considering importing XHTML Modularization DTDs for use with local
catalogs of the W3C markup validator, I found the following public id related
issues with it (applies to REC-xhtml-modularization-20081008, ED-xhtml-
modularization-20091007, and the currently available files at
http://www.w3.org/MarkUp/DTD/)

1) xhtml.cat refers to the following modules/DTDs which are not included in
the REC-xhtml-modularization-20081008 or ED-xhtml-modularization-20091007
downloadable tarballs: xhtml-ruby-1.mod, xhtml11-arch.dtd, xhtml-redecl-1.mod.
(This is not an issue for http://www.w3.org/MarkUp/DTD/xhtml.cat, just the
tarballs.)

2) xhtml.cat has this public id for xhtml-edit-1.mod:
"-//W3C//ELEMENTS XHTML Editing Elements 1.0//EN"
...but the module itself has in its comments:
"-//W3C//ELEMENTS XHTML Editing Markup 1.0//EN"
...and the latter is not in xhtml.cat. Which one of these should the public
id for xhtml-edit-1.mod be? Should the comment in module or the catalog be
corrected, or are both good and both should be included in xhtml.cat? A quick
web search produces hits for both public ids in the wild.

3) Similarly as 2) above, xhtml.cat has this public id for xhtml-bdo-1.mod:
"-//W3C//ELEMENTS XHTML BIDI Override Element 1.0//EN"
...but the module itself has in its comments:
"-//W3C//ELEMENTS XHTML BDO Element 1.0//EN"
...and the latter is not in xhtml.cat. Which one of these should the public
id for xhtml-bdo-1.mod be? Should the comment in the module or the catalog be
corrected, or are both good and both should be included in xhtml.cat? A quick
web search produces hits for both public ids in the wild.

Ville

Re: [XHTML Basic 1.1 2e] Typo in example in 5.5

2009-10-01T03:43:25Z

Fixed in the source - will update the public editor's draft soon.
Thanks for your comment!

Steven Pemberton wrote:
> Email: <input name="zip" inputmode="latin lowerCase" />
> should be
> Email: <input name="email" inputmode="latin lowerCase" />
>
> Steven
>
>

--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: shane@...

[XHTML Basic 1.1 2e] Typo in example in 5.5

2009-10-01T00:56:44Z

Email: <input name="zip" inputmode="latin lowerCase" />
should be
Email: <input name="email" inputmode="latin lowerCase" />

Steven

location of the MathML DTD referenced from REC-xhtml1-20020801

2009-09-29T05:25:21Z

Appendix E of the XHTML 1.0 recommendation says:

[XHTML+MathML] is Available at:
http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd

however since MathML 2 2nd edition the location is

http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd

Unfortunately the copy at /TR/MathML2/dtd/ is still there (relating to
earlier versions of MathML) and generates errors with some common XML
parsers, in particular due to lack of namespace awareness in the choice
of processing instruction names.

SXXP0003: Error reported by XML parser: A colon is not allowed in
the name 'IS10744:arch'

The use of IS10744:arch affects all the "standard" xhtml dtd as well as
the xhtml+mathml one.

Newer (since 2002) versions of the XHTML+MathML DTD from
http://www.w3.org/Math/DTD/mathml2/
or
http://www.w3.org/Math/DTD/mathml3
have these problematic constructs removed.

It would be good if an errata entry could be made updating the
reference. Even better would be if

http://www.w3.org/TR/MathML2/dtd

redirected to

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

but I'm not sure if that is allowed because of the stability
requirements of the TR area.

David

(Maintainer of the MathML DTD responding to reports about the old
MathML DTD, which a user confirmed he was led to by this reference in
the XHTML recommendation.)

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________

Re: What happened to input/@ismap?

2009-09-23T05:31:22Z

This seems to be an error no one has spotted before. There are no plans to
update XHTML 1.0, so this error will have to remain I am afraid.

Best wishes,

Steven Pemberton

On Sun, 13 Sep 2009 17:23:09 +0200, Kristof Zelechovski
<giecrilj@...> wrote:

> HTML 4.01 has input/@ismap[1], XHTML 1.0 does not[2]. Why?
>
>
> _____
>
> [1] http://www.w3.org/TR/html401/interact/forms.html#edef-INPUT
>
> [2] XHTML
> <http://www.w3.org/TR/html/dtds.html#dtdentry_xhtml1-strict.dtd_input>
> 1.0
> - DTDs
>

Re: Error in HTML 4.01: invalid example for ABBR

2009-09-23T05:29:08Z

Thanks. Indeed the content of the element should be D<sup>a</sup>.
However, there are no plans to reissue the HTML4 spec, so this mistake
will not be corrected.

Best wishes,

Steven Pemberton

On Sat, 19 Sep 2009 19:18:22 +0200, Kristof Zelechovski
<giecrilj@...> wrote:

> The HTML 4.01 Specification[1] contains the following example[2]
>
> <ABBR lang="es" title="Doña">Doña</ABBR>
>
> This is wrong: a word is not an abbreviation for itself.
>
> Please fix.
>
> Chris
>
>
> _____
>
> [1] HTML 4.01 Specification
> <http://www.w3.org/TR/1999/REC-html401-19991224>
>
>
> [2]
> <http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#edef-ABBR>
> 9.2.1 Phrase elements
>

Error in HTML 4.01: invalid example for ABBR

2009-09-19T10:18:22Z

The HTML 4.01 Specification^{^[1]} contains the following example^{^[2]}

<ABBR lang="es" title="Doña">Doña</ABBR>

This is wrong: a word is not an abbreviation for itself.

Please fix.

Chris

^{^[1]} HTML 4.01 Specification

^{^[2]} 9.2.1 Phrase elements

What happened to input/@ismap?

2009-09-13T08:23:09Z

HTML 4.01 has input/@ismap^{^[1]}, XHTML 1.0 does not^{^[2]}. Why?

^{^[1]} http://www.w3.org/TR/html401/interact/forms.html#edef-INPUT

^{^[2]} XHTML 1.0 - DTDs

MAP content model correction

2009-09-11T00:32:36Z

Regarding XHTML 1.0 - DTDs:

               <!ELEMENT map ((%block; | form | %misc;)+ | area+)>

Should be

               <!ELEMENT map ((%Block;)+ | area+)>

The present definition of %Block is:

        <!ENTITY % Block "(%block; | form | %misc;)*">

Should be:

        <!ENTITY % Block "%block; | form | %misc;">

References to %Block; elsewhere should be replaced with references to (%Block;)+

Motivation: better modularity, easier to implement a validator following the DTD.

Please consider.

Note also that according to The global structure of an HTML document the BODY element cannot be empty, whereas the XHTML DTD allows it to be, and it is not discussed among XHTML 1.0 - Differences with HTML 4. I think the difference is unintended and the discrepancy should be removed.

Please fix ASAP.

Best regards,

Chris

XHTML Basic 1.1 Errata

2009-09-04T10:40:46Z

Hello,

just translated HTML Basic 1.1 into German.

In my opinion there is a small mistake in the specification.

Section 5.2, paragraph beginning with "Second":
For each token t in the inputmode attribute, if in the remaining list
of tokens representing available input modes

remaining list of tokens
should be:
remaining lists of tokens

So long
Stefan

--
IT und EDV Management
Stefan Schumacher
Loh 15 Golden Glades 151
58339 Breckerfeld Kamshet, INDIA
Tel: +49 172 2718968 +91 9923670737
www.schumacher-netz.de
www.gleitschirm-fernweh.de

Re: Use of empty element shortcut for accidentally empty elements.

2009-08-20T07:47:10Z

<p/> is in fact correct XHTML 1, and the validator is correct in allowing
it.

Section 4.3 explains that in XHTML 1.0, you must terminate all elements
(SGML and HTML terminate some elements for you).
So you must write
<p>Para 1</p><p>Para 2</p>
where you used to be able to write
<p>Para 1<p>Para 2

However, the informative (rather than normative) guideline in section C.3
points out that if you want your XHTML 1.0 documents to work in both XHTML
and HTML user agents, then you should use <p></p> instead of <p/>, since
HTML user agents don't recognise the <p/> form.
(C.2 points out that for similar reasons you should use <br/> and not
<br></br>).

Note that there is a more up-to-date set of guidelines at
http://www.w3.org/TR/xhtml-media-types/#compatGuidelines

Hope this helps.

Best wishes,

Steven Pemberton

On Thu, 20 Aug 2009 16:28:51 +0200, Colin Fine <colin.fine@...> wrote:

> Some while ago I realised that the XHTML1.0 spec (in section 4.3)
> licences the empty element shortcut (<xxx/>) only for elements defined
> as empty in the DTD; so that <br/> is legal but <p/> is not.
>
> Recently I pointed this out to somebody on a mailing list
> (http://groups.google.com/group/prototype-scriptaculous/t/7df119e31a7c30a9?hl=en)
> and he replied that the W3C validator accepted forms such as <p/>.
>
> I have verified that this is the case.
>
> As things stand, this appears to me to be a bug in the validator - or is
> there some sort of update to the spec which allows it?
>

Use of empty element shortcut for accidentally empty elements.

2009-08-20T07:28:51Z

Some while ago I realised that the XHTML1.0 spec (in section 4.3)
licences the empty element shortcut (<xxx/>) only for elements defined
as empty in the DTD; so that <br/> is legal but <p/> is not.

Recently I pointed this out to somebody on a mailing list
(http://groups.google.com/group/prototype-scriptaculous/t/7df119e31a7c30a9?hl=en)
and he replied that the W3C validator accepted forms such as <p/>.

I have verified that this is the case.

As things stand, this appears to me to be a bug in the validator - or is
there some sort of update to the spec which allows it?

--

*Colin Fine*
*****Engineering Tools Group
Pace plc*
*/Bringing Technology Home/*

*Tel: +44 1274 538038*
*****Fax: +44 1274 538056*
*Victoria Road, Saltaire, West Yorkshire. BD18 3LF _
__www.pace.com_*

*/Think before you print! Please consider the environment before
printing this e-mail./*

Visit Pace at IBC 2009
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. <http://www.pace.com>
Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace's standard terms and conditions of sale which may have been provided to you, or in any event are available at http://www.pace.com/uktcsale.pdf (ii) all orders for goods and/or services placed by Pace are subject to Pace's standard terms and conditions of purchase which may have been provided to you, or in any event are available at http://www.pace.com/uktcpurch.pdf. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

CURIE spec: URIorSafeCURIE capitalization error-prone

2009-08-10T12:40:21Z

CURIE spec: URIorSafeCURIE capitalization error-prone

Regarding the CURIE specification currently at http://www.w3.org/TR/curie/
(http://www.w3.org/TR/2009/CR-curie-20090116):

In the datatype names URIorSafeCURIE and URIorSafeCURIEs, the
inconsistent capitalization of initial letters of words (specifically,
the lack of capitalization of the "o" in "or") seems very like to
lead to errors.

Yes, leaving "or" in all lower case does follow standard English
capitalization, but since these are computer-related identifiers, not
English titles, the word "or" should also have its first letter
capitalized, per normal camel-case conventions.

Daniel
--
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]

CURIE spec. editorial errors

2009-08-10T12:29:36Z

CURIE spec. editorial errors

The document currently at http://www.w3.org/TR/curie/
(http://www.w3.org/TR/2009/CR-curie-20090116) contains several editorial
errors:

* Section 1 says:

     Moreover, in this example, we want the names within that scope to
     a URI that will reveal the meaning of that ISBN.

   (Something is missing (perhaps "to map").)

* Section 1 says

     ... the syntax of QNames is overly-restrictive ..

   The hyphen isn't needed in that case (because "overly" is an
   adverb).

* Section 1 says:

     CURIEs expand to any IRI. QNames are treated as value pairs, but
     even if those pairs are combined into a string, only a subset of
     IRIs can be represented.

   Something is really unclear in that first sentence. It does not
   convey the its apparent intended meaning because of its imprecision.
   (The set of all CURIEs does _not_ expand to any single IRI.)

   The paragraph should probably first be written in terms of singular
   items, e.g.: "A CURIE expands to an IRI. A QName is treated as a
   value pair ..." (Obviously, second, the part about being able to
   represent any IRI needs to be re-added somehow.)

* Section 2.2 says:

     ... "URI-references, IRI-references" ..

   Those hyphens are extraneous.

* Section 3 says:

     The following definition makes the set of CURIEs a syntactic
     superset of the set of QNames. It is comprised of two
     components, a prefix and a reference. ...

       safe_curie :=   '[' curie ']'

       curie       :=   [ [ prefix ] ':' ] reference

       prefix      :=   NCName

       reference   :=   irelative-ref (as defined in IRI)

   First, the "is comprised of" is backwards. (A whole comprises its
   parts (or is _composed_ of them); it is not "comprised of" its
   parts.)

   Second, it is not the definition that comprises two components.
   (The first and second sentences are not coordinated right--as
   things are written, the "it" refers to "the following definition,"
   not to "a CURIE" or "the curie production.")

* Section 3 says:

     Such reserved values MUST translate into an IRI, just as with any
     other CURIE.

   That wording doesn't say what it (apparently) means. It should say
   something like:

     Such a reserved value MUST translate into an IRI, just as with any
     other CURIE.

* Section 3 says:

     Host languages MAY define additional constraints on these syntax
     rules when CURIES are used ...

   (The "s" is capitalized.)

* Section 4.1 says:

     The [SPARQL] language provides ...

   Shouldn't that really be something like the following?

     The SPARQL language [SPARQL] provides ...

   (That is, the bracketed text represents a footnote reference, so
   the sentence should be readable without that text, right? So
   writing "The [SPARQL] language provides ..." reads as "The
   language provides ...," which certainly isn't the intent.

   For example, see the SPARQL spec's section 1.2.2
   (http://www.w3.org/TR/rdf-sparql-query/#docDataDesc):

     This document uses the Turtle [TURTLE] data format to ...
   )

(_If_ W3C specifications are to be in American English: The phrases
quoted with single quotes should use double quotes.)

Daniel
--
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]

http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/#a_example typo?

2009-07-17T10:41:23Z

http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/#a_example has the following two lines:

<!-- use lang and xml:lang if your language supports it - A.7 -->

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

It seems to me that the second line is missing 'lang="en"'. I think it should be

<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">

Thanks for your good work.

Re: What Kind of a Group is this and How I become member of this group?

2009-06-29T13:56:15Z

On 6/29/09, Kamaal <kamal@...> wrote:
>
>
> Hello,
>
> What kind of a Group is this and how I become member of this group? Is
> there any Member or Moderator or Admin know me well?

Responding so that those, as I, who received it, know its origin.. A
quick peek at the source reflected this www-html-editor listserv
addy.. :)

Happy Monday to All.. :)

Cindy Sue

- :: -
Celebrating Community Choice and Independent Living!

http://claimid.com/butterfly
Georgia Voices That Count, 2005
Talking Rock, GA, USA

What Kind of a Group is this and How I become member of this group?

2009-06-29T13:11:35Z

Hello,

What kind of a Group is this and how I become member of this group? Is
there any Member or Moderator or Admin know me well?

Please send more information or unsubscribe me!

Thanks

Kamaal
--
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "IBroadcast Qatar" group.
To post to this group, send email to ibroadcast-qatar@...
To unsubscribe from this group, send email to ibroadcast-qatar+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/ibroadcast-qatar?hl=en
-~----------~----~----~----~------~----~------~--~---

XHTML Media Types

2009-06-20T03:37:38Z

Hello all,

while reviewing the updated <http://www.w3.org/TR/xhtml-media-types/>,
I noticed the following errors and omissions:

| A.2. Elements that can never have content
| [...]
| Rationale: HTML user agents ignore the /> at the end of a tag, [...]

I am afraid that statement, in its absoluteness, is plain wrong. (It was
also in XHTML 1.0, Appendix C, and is addressed in my criticism of that
section to define a variant of XHTML 1.0 that would be "HTML-compatible".
Because, strictly speaking, HTML and XHTML are *incompatible*. But I digress.)

It is merely correct to say that some HTML UAs, maybe many of them, ignore
the `/'. It is incorrect to say that "HTML UAs" (implies in that context:
all) do, because there are standard-conforming HTML UAs that treat `/>' like
`>>'; most notably, the current version of the W3C Markup Validator, but
there are also practical examples:

<http://dodabo.de/html+css/tests/shorttag.html>

You will notice that these include Links and lynx, which are known to
provide input for screen readers and Braille lines (for people with impaired
vision, and blind people), and thus cannot be reasonably discounted. So it
seems only fair to mention in the guideline, at least, that serving XHTML as
text/html as suggested can, at least, create accessibility issues.

| A.4. Embedded Style Sheets and Scripts
|
| DO use external style sheets if your style sheet uses < or & or ]]> or
| --. DO NOT use an internal stylesheet if the style rules contain any of
| the above characters.
|
| DO use external scripts if your script uses < or & or ]]> or --. DO NOT
| embed a script in a document if it contains any of these characters

In my opinion, mentioning `--' like this is misleading. AFAICS, it will do
no harm to a stylesheet or a script unless it is preceded by `<!', and the
corresponding section has not been marked up as CDATA. This should be
clarified.

In addition, it should be pointed out that

<script ...></script>

(including cases with white-space before `<!..', or after `-->', or `//'
before `<!--') is considered harmful as it will comment out the `script'
element's content in XHTML parsed by an XML UA (content model: PCDATA), and
at least the last line will lead to script syntax errors (invalid operand
for pre-decrement) in XHTML parsed by an HTML UA (content model: CDATA).

HTML 2.0 (RFC 1866), which did not yet have the SCRIPT element, is OBSOLETE
since about 9 years (RFC 2854, 2000-06 CE) now, so UAs still requiring this
should be considered borken. Pre-HTML-3.2/4.01 (Browser War I era) UAs are
pretty much obsolete by now, too. (That said, there was never a real need
to hide script code in the HEAD element, which is where most people appear
to use it.)

So developers should be advised that the pseudo-CDO and -CDC should simply
be omitted from scripts. (HTML 4.01 [1999-12-24] did not make that clear,
nor did XHTML 1.0, Second Edition [2002-08-01], Appendix C. It is [thus?] a
frequent issue in [de.]comp.lang.javascript where I am a regular contributor.)

| A.6. Deleted
|
| This guideline was deleted because it is no longer relevant.

I suggest deleting this subsection as it is more confusing than helpful.
If it was relevant before, one should find a note of its deletion in the
document history. One would have to look up a previous version of the WG
Note in any case.

| A.11. Document Object Model and XHTML
| [...]
| For example, in JavaScript you might do something like:
|
| ...
| var name=node.name().toLowerCase;
| if ( name == 'table' ) {
| ...
| }

MUST be (to work, and make sense):

var name=node.nodeName.toLowerCase();
// ...

SHOULD be at least:

var elName = node.nodeName.toLowerCase();
if (elName === "table") {
...
}

(`name' is an identifier unwise to choose. For example, Window objects
already have a `name' property that might be shadowed with this, and `name'
could as well indicate the name of HTML DOM object representing a form control.

Changes in quotes only because I think double-quotes are better legible, and
apostrophes, aka single-quotes, should only be used when necessary.)

However, since HTML user agents are supposedly still in the majority, and
that I know of yield an uppercase node name, the following would be more
efficient overall:

var elName = node.nodeName.toUpperCase();
if (elName === "TABLE") {
...
}

or

if (/^TABLE$/i.test(node.nodeName) {
...
}

as Regular Expressions and RegExp initializers are specified since
ECMAScript Edition 3, and supported since JavaScript 1.2, JScript
3.1.3510 (supposedly 3.0), whereas both predate it, and at least
Opera 5.02. (See also: <http://PointedEars.de/es-matrix>)

| A.21. document.write
| [...]
| Rationale: Native XML user agents may not support this technique for
| modifying the content of the document.

You are correct, for example Netscape/Mozilla Gecko does not support
document.write() in XML mode. I cannot remember of any user agent that
does. However, it would appear that this is either a bug in those user
agents, or W3C DOM Level 2 HTML is incorrect/imprecise. For the latter
says that

| 1.1. Introduction
|
| This section extends the DOM Level 2 Core API [DOM Level 2 Core] to
| describe objects and methods specific to HTML documents [HTML 4.01],
| and XHTML documents [XHTML 1.0].

but it defines HTMLDocument::write(), which is implemented as document.write().

<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-75233634>

Maybe you could clarify this (in cooperation with the DOM Working Group)?

As for the rest, thank you very much for the update; you have pointed out
some important issues regarding compatibility that were not in the first
edition, and that will help us in the future.

I would suggest you consider removing Appendix C from XHTML 1.0 in the next
revision, and to refer to the WG Note instead.

I am looking forward to your reply. Thank you in advance.

Kind regards,

PointedEars

[xhtml-media-types] A. 19 and XHTML Basic 1.1

2009-06-17T01:12:36Z

Hello.

I got a blog comment which questioned about the relationship between
XHTML Basic 1.1 and Media Types document, and found that interesting.
So let me share that.

The guy pointed out guideline A.19 in xhtml-media-types, which
suggests to write <tbody> explicitly.

>A.19. Explicit <tbody> Elements
>
> DO use explicit tbody elements within tables.
>
> Rationale: While the content model of the table element permits the
> tbody element to be skipped, in HTML 4 this element is implicit.
> HTML 4 user agents will silently add this element, thus potentially
> confusing scripts or style sheets.

However, <tbody> is not defined in Basic 1.1 since it only contains
Basic Table module.

He said he wondered whether he cannot use tables in Basic 1.1 to
follow the guideline.
I'm sure that's not what the guideline is intended (I think he seemed
to be, too). But perhaps that guideline should say it doesn't apply to
profiles that don't contain <tbody>.

Regards,
--
Masataka Yakura
<myakura.web@...>

Re: XHTML1: Suggested improvements to Appendix C (PR#6232)

2009-06-02T11:44:52Z

On Tue, 2 Jun 2009, Shane McCarron wrote:

>
> 5.1. Internet Media Type
>
> XHTML 1.0 documents SHOULD be labeled with the Internet Media Type
> "application/xhtml+xml" as defined in [RFC3236
> <http://www.w3.org/MarkUp/2009/ED-xhtml1-20090602/#ref-rfc3236>]. For
> informaiton on delivering XHTML 1.0 Documents to user agents that do not
> natively handle this media type, see the informative note [XHTMLMIME
> <http://www.w3.org/MarkUp/2009/ED-xhtml1-20090602/#ref-xhtmlmime>].
>
> [1] http://www.w3.org/MarkUp/2009/ED-xhtml1-20090602

That's much better, thanks.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

Re: XHTML1: Suggested improvements to Appendix C (PR#6232)

2009-06-02T09:02:10Z

Ian,

Thanks for your comments. In the call today we discussed how to try to
address (what we felt was) your core objection - that of normatively
defining handling for text/html. While the group does NOT agree that
this draft document normatively requires anything with regard to
text/html, we do agree that the text in section 5.1 was poor. We
suggest the following new wording, also reflected in [1]:

5.1. Internet Media Type

XHTML 1.0 documents SHOULD be labeled with the Internet Media Type
"application/xhtml+xml" as defined in [RFC3236
<http://www.w3.org/MarkUp/2009/ED-xhtml1-20090602/#ref-rfc3236>]. For
informaiton on delivering XHTML 1.0 Documents to user agents that do not
natively handle this media type, see the informative note [XHTMLMIME
<http://www.w3.org/MarkUp/2009/ED-xhtml1-20090602/#ref-xhtmlmime>].

[1] http://www.w3.org/MarkUp/2009/ED-xhtml1-20090602

Ian Hickson wrote:

> On Thu, 28 May 2009, Shane McCarron wrote:
>
>>> Do you have a link to the most recent editor's draft of the XHTML
>>> specification so that I can see if the new text addresses my comments?
>>>
>> Sure. W3C XHTML 2 Drafts are publicly available via our drafts page [1]
>> - within that page you will find an updated XHTML 1 editors draft we are
>> preparing for PER - the latest is [2]. You might also want to look at
>> the Working Group Note that was published earlier this year [3].
>>
>> [1] http://www.w3.org/MarkUp/Drafts
>> [2] http://www.w3.org/MarkUp/2009/ED-xhtml1-20090528/
>> [3] http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/
>>
>
> Thanks.
>
> With respect to the issue quoted below (PR#6232), I do not find the
> working group's response to be satisfactory, as the underlying problem is
> still present in the XHTML 1.0 3rd edition draft.
>
> Specifically, I object to the following comment in section 5.1:
>
> : XHTML Documents which follow the guidelines set forth in [XHTMLMIME]
> : may be labeled with the Internet Media Type "text/html" [RFC2854]
> -- http://www.w3.org/MarkUp/2009/ED-xhtml1-20090528/#media
>
> My original comments stand, namely that I request that either this prose
> be removed, disallowing XHTML documens to be sent as text/html, or that
> the guidelines set forth in [XHTMLMIME] have the changes listed below made
> to them, including in particular making the guidelines normative, and that
> the text following the above phrase, namely:
>
> : [...] as they are compatible with most HTML browsers.
> -- http://www.w3.org/MarkUp/2009/ED-xhtml1-20090528/#media
>
> ...be changed to refer to "legacy Tag Soup user agents" or some similar
> wording that admits that XHTML cannot be made compatible with HTML, only
> with the error handling code of existing user agents.
>
> Thank you for responding to my comments.
>
>
>
>>>>> I believe the XHTML1 spec is wrong to allow XHTML to be sent as
>>>>> text/html. While in theory XHTML1 can be made compatible with Tag Soup
>>>>> UAs while still being valid and correct, the reality is that few
>>>>> authors are able to do so.
>>>>>
>>>>> I recommend that the working group consider releasing another edition
>>>>> of XHTML1, that removes the ability to send XHTML as text/html.
>>>>>
>>>>> However, if the working group does not wish to do this, I believe the
>>>>> following changes need to be made to appendix C:
>>>>>
>>>>> 1. Make the appendix normative.
>>>>>
>>>>> 2. Change "on existing HTML user agents" to "on legacy Tag Soup user
>>>>> agents" or some similar wording that admits that XHTML cannot be
>>>>> made compatible with HTML, only with the error handling code of
>>>>> existing user agents.
>>>>>
>>>>> 3. Change the suggestion that XML declarations should be omitted to
>>>>> a more strongly worded recommendation, as XML PIs trigger quirks
>>>>> mode in WinIE6 and are displayed verbatim on PocketIE.
>>>>>
>>>>> 4. Remove one of the duplicated sentences in "C.4. Embedded Style
>>>>> Sheets and Scripts", and require that script and style blocks be
>>>>> neither "commented out" (with ), nor enclosed in CDATA
>>>>> blocks, nor include any entities.
>>>>>
>>>>> 5. Add a section requiring that <tbody> not be omitted.
>>>>>
>>>>> 6. Change the "C.11. Document Object Model and XHTML" section
>>>>> slightly so that it requires that scripts be aware that when
>>>>> treated as XML, they should use the namespace-aware Core APIs,
>>>>> and when treated as HTML, it should use the DOM1 Core APIs;
>>>>> similarly, that all script compare tagNames and attributes by
>>>>> lowercasing them first.
>>>>>
>>>>> 7. Require that stylesheets style the HTML element rather than the
>>>>> BODY element.
>>>>>
>>>>> 8. Documents should not use the <meta http-equiv="Content-Type">
>>>>> element. (Actually this applies to all XHTML.)
>>>>>
>>>>> 9. There should be no use of namespaces other than the XHTML one.
>>>>> (This is true of all valid XHTML elements anyway.)
>>>>>
>>>>> 10. There should be no XML Stylesheet PIs anywhere. (See 3)
>>>>>
>>>>> Overall, I think the language should be made more strict ("MUST"s
>>>>> rather than "SHOULD" or "MAY"). Stricter requirements are a great help
>>>>> when evangelising the use of correct markup.
>>>>>
>
>

--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: shane@...

Re: XHTML1: Suggested improvements to Appendix C (PR#6232)

2009-05-28T14:54:33Z

On Thu, 28 May 2009, Shane McCarron wrote:

> >
> > Do you have a link to the most recent editor's draft of the XHTML
> > specification so that I can see if the new text addresses my comments?
>
> Sure. W3C XHTML 2 Drafts are publicly available via our drafts page [1]
> - within that page you will find an updated XHTML 1 editors draft we are
> preparing for PER - the latest is [2]. You might also want to look at
> the Working Group Note that was published earlier this year [3].
>
> [1] http://www.w3.org/MarkUp/Drafts
> [2] http://www.w3.org/MarkUp/2009/ED-xhtml1-20090528/
> [3] http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/

Thanks.

With respect to the issue quoted below (PR#6232), I do not find the
working group's response to be satisfactory, as the underlying problem is
still present in the XHTML 1.0 3rd edition draft.

Specifically, I object to the following comment in section 5.1:

: XHTML Documents which follow the guidelines set forth in [XHTMLMIME]
: may be labeled with the Internet Media Type "text/html" [RFC2854]
-- http://www.w3.org/MarkUp/2009/ED-xhtml1-20090528/#media

My original comments stand, namely that I request that either this prose
be removed, disallowing XHTML documens to be sent as text/html, or that
the guidelines set forth in [XHTMLMIME] have the changes listed below made
to them, including in particular making the guidelines normative, and that
the text following the above phrase, namely:

: [...] as they are compatible with most HTML browsers.
-- http://www.w3.org/MarkUp/2009/ED-xhtml1-20090528/#media

...be changed to refer to "legacy Tag Soup user agents" or some similar
wording that admits that XHTML cannot be made compatible with HTML, only
with the error handling code of existing user agents.

Thank you for responding to my comments.

> > > > I believe the XHTML1 spec is wrong to allow XHTML to be sent as
> > > > text/html. While in theory XHTML1 can be made compatible with Tag Soup
> > > > UAs while still being valid and correct, the reality is that few
> > > > authors are able to do so.
> > > >
> > > > I recommend that the working group consider releasing another edition
> > > > of XHTML1, that removes the ability to send XHTML as text/html.
> > > >
> > > > However, if the working group does not wish to do this, I believe the
> > > > following changes need to be made to appendix C:
> > > >
> > > > 1. Make the appendix normative.
> > > >
> > > > 2. Change "on existing HTML user agents" to "on legacy Tag Soup user
> > > > agents" or some similar wording that admits that XHTML cannot be
> > > > made compatible with HTML, only with the error handling code of
> > > > existing user agents.
> > > >
> > > > 3. Change the suggestion that XML declarations should be omitted to
> > > > a more strongly worded recommendation, as XML PIs trigger quirks
> > > > mode in WinIE6 and are displayed verbatim on PocketIE.
> > > >
> > > > 4. Remove one of the duplicated sentences in "C.4. Embedded Style
> > > > Sheets and Scripts", and require that script and style blocks be
> > > > neither "commented out" (with ), nor enclosed in CDATA
> > > > blocks, nor include any entities.
> > > >
> > > > 5. Add a section requiring that <tbody> not be omitted.
> > > >
> > > > 6. Change the "C.11. Document Object Model and XHTML" section
> > > > slightly so that it requires that scripts be aware that when
> > > > treated as XML, they should use the namespace-aware Core APIs,
> > > > and when treated as HTML, it should use the DOM1 Core APIs;
> > > > similarly, that all script compare tagNames and attributes by
> > > > lowercasing them first.
> > > >
> > > > 7. Require that stylesheets style the HTML element rather than the
> > > > BODY element.
> > > >
> > > > 8. Documents should not use the <meta http-equiv="Content-Type">
> > > > element. (Actually this applies to all XHTML.)
> > > >
> > > > 9. There should be no use of namespaces other than the XHTML one.
> > > > (This is true of all valid XHTML elements anyway.)
> > > >
> > > > 10. There should be no XML Stylesheet PIs anywhere. (See 3)
> > > >
> > > > Overall, I think the language should be made more strict ("MUST"s
> > > > rather than "SHOULD" or "MAY"). Stricter requirements are a great help
> > > > when evangelising the use of correct markup.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

value for class attribute should be CDATA (not NMTOKENS)

2009-05-25T21:18:27Z

A document containing an element which has a class attribute with
an empty value (for example, <div class="">) is valid in XHTML 1.0
(and in HTML 4.01), but it seems like the XHTML 1.1 specification
redefines the value of the class attribute in such a way that it's
no longer valid in XHTML 1.1

For the record, here are the details:

In the XHTML Common Attribute Definitions section[1] of the XHTML
Modularization 1.1 specification, the value of the class attribute
is defined as NMTOKENS:

[1] http://www.w3.org/TR/2008/REC-xhtml-modularization-20081008/dtd_module_defs.html#a_module_XHTML_Common_Attribute_Definitions

But in the XHTML 1.0 DTDs (and in HTML 4.01), the value of the
class attribute is defined[2] as CDATA:

[2] http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_coreattrs

This seems to be a substantive change, but it's not documented in
the Changes from XHTML 1.0 Strict section[3] of the XHTML 1.1
specification, http://www.w3.org/TR/xhtml11/changes.html -- and
I've not so far been able to find any record of an announcement
about that change (nor any record of discussion about it at all).

Anyway, I note that the XML spec defines NMTOKENS as a space-
separated list of one or more NMTOKEN, and each NMTOKEN must be
one or more name characters, http://www.w3.org/TR/xml/#NT-Nmtoken

Nmtokens ::= Nmtoken (#x20 Nmtoken)*
Nmtoken ::= (NameChar)+

So as far as I can see from that, any attribute whose value is
defined as NMTOKENS must not be empty. So by redefining the value
of the class attribute from CDATA to NMTOKENS, the XHTML 1.1
specification introduces a change that's not backward compatible
with existing XHTML 1.0 content -- a change that'll cause users to
find that their existing XHTML 1.0-valid documents containing
empty class attributes are no longer considered valid in XHTML 1.1

--Mike

--
Michael(tm) Smith
http://people.w3.org/mike/

Improve the Quality of your Sleep

2009-05-20T11:21:13Z

Studies have shown that insufficient sleep is the leading cause for stress related diseases. Your 7-9 hours of downtime every night actually help you eliminate stress, regenerate your energy levels, repair any damages in your body and recover or fight off diseases. Stress and a lack of sleep can cause a variety of health related problems, many of which can be serious.

Many people suffer from sleeping disorders such as difficulty falling asleep, sleeping through the night and even more commonly a lack of quality sleep. Sleep is not only necessary in quantity, but even more importantly quality. Do you sleep through the night but wake up exhausted? Perhaps you are getting the number of hours you need, but not the deep sleep you need just as much! What people don't know that this problem is now easily solved!

Melatrol will help you fall asleep faster, deeper and provides you with a better quality sleep so you can enjoy a productive day! There is no need to depend on caffeine to get you going in the morning; there is no need to put up with mood swings and anxiety due to a lack of sleep!

For more details and information, send us a request at 1698ridlen.barbara@... and we will get back to you shortly.

Best regards,
Sleep Solutions Marketing

------------------------------------------------------------------
This email has been written and proved to be in compliance with the recently established can-spam act law in US. We are not provoking or forcing any person in any way to participate in our programs. To participate is your own decision and you carry the responsibility of taking further part in this promotion. Anyway, if you don't want to receive more good offers from us, you can simply Unsubscribe by sending us a notification email to get.out_from_list@... with a mail-subject and text "Unsubscribe me", and we will get your email out of our list within 10 days.

This message is STRICTLY CONFIDENTIAL and is solely for the individual or organisation to whom it is addressed. It may contain PRIVILEGED and CONFIDENTIAL information. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication and its contents is strictly prohibited. If you are not the intended recipient you should not read, copy, distribute, disclose or otherwise use the information in this email. Email may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or the consequences thereof or your reliance on any information contained therein if you are not the intended recipient. If you are not interested in the offered promotions, please just don't answer. If you think you have received this message and its contents in error, please delete it from your computer, or follow the unsubscribing procedure shown above.
------------------------------------------------------------------

Hi friend,

2009-05-19T13:13:13Z

Hi friend,
how are you doing recently ? I would like to introduce you a very good company which i knew.Their website is www.elewholesale.com .They can offer you all kinds of electronical products which you need like laptops ,gps ,TV LCD,cell phones,ps3,MP3/4,motorcycles etc........Please take some time to have a check ,there must be somethings you 'd like to purchase .
Their contact email: eleintrade@....

MSN: eleintrade01@...
Hope you have a good mood in shopping from their company !
Regards

xhtml11-flat.dtd corrupted in ZIP and TGZ downloads

2009-04-30T17:09:24Z

Hello,

it looks like the file

/DTD/xhtml11-flat.dtd

in both of the downloads from

<http://www.w3.org/TR/xhtml11/xhtml11.zip>
and
<http://www.w3.org/TR/xhtml11/xhtml11.tgz>

is corrupt. It has text "]><html><head><title>title</title></
head><body><p>text</p></body></html>" at its very end, and an XML parser
reports the file to be an invalid DTD file.

Kind regards
Christian Roth