W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

RE: [widgets] P&C Last Call comments, 1

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Tue, 2 Jun 2009 11:26:59 +0200
To: "marcosc@opera.com" <marcosc@opera.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C0A26ED8FF5@OBEEX01.obe.access-company.com>
Hi Marcos,

Thanks for fixes.

>> Unify i.e. (i.e.,) and e.g. (e.g.,) to follow fully either American- or British-English.
>I'm not sure what you mean?
Probably it is too pedantic, but I found this:



Kind regards,

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Monday, June 01, 2009 11:43 AM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [widgets] P&C Last Call comments, 1

Hi Marcin,

One question below.

On Mon, Jun 1, 2009 at 12:44 AM, Marcin Hanclik
<Marcin.Hanclik@access-company.com> wrote:
> EDITORIALs and Global stuff
> Unify "inform an" vs. "inform the" throughout the full document.


> Unify i.e. (i.e.,) and e.g. (e.g.,) to follow fully either American- or British-English.

I'm not sure what you mean?

> Should not the RFC2119 terms in authoring guidelines be also in uppercase?

No, they are non-normative.

> What is the normative status of the authoring guidelines?

"As well as sections marked as non-normative, authoring guidelines,
diagrams, examples, and notes in this specification are non-normative.
Everything else in this specification is normative."

> Term API is not defined.
As APIs are not relevant to the P&C spec, I have not given it a formal
definition. However, I've added <abbr title="application programming
interface">API</abbr> where the abbreviation appears.

> Maybe <...> notation could be used for all elements, not only for <its:span>?

I removed the < and > from its:span.

> Zip or zip could be used consistently within the document.

Changed all zip to Zip where appropriate.

> 1.4
> Could this section (and the similar content from the family specs) be moved to a separate document?

The WG is still discussing if we are going to have an overarching
"Widgets" document. Until then, that text will have to live there.
It's only one paragraph, it really does not harm.

> 3.2
> its:span
> should be
> <its:span>

I've removed the < and > to be consistent with the rest of the document.

> 4.
> assists them making
> should be
> assists them in making


> 5.
> .Zip file
> may be
> .zip file

Changed it to .ZIP file, as per the ZIP spec.

> 5.2
> minimum version supported version
> should be
> minimum supported version


> the the CC MUST
> should be
> the CC MUST


> 5.3
> it is recommended  that a user agent internally treat all zip-relative
> should be
> it is recommended  that a user agent internally treats all zip-relative


Marcos Caceres


Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda


This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Tuesday, 2 June 2009 09:28:11 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:16 UTC