W3C home > Mailing lists > Public > public-webarch-comments@w3.org > May 2004

Re: 10 May 2004 Editor's Draft of Architecture Document - reviewer ?responses requested

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: 11 May 2004 14:59:32 -0400
To: "Ian B. Jacobs" <ij@w3.org>
Cc: public-webarch-comments@w3.org, www-tag@w3.org
Message-Id: <1084301969.2831.74.camel@30-5-97.wireless.csail.mit.edu>

On Mon, 2004-05-10 at 21:31, Ian B. Jacobs wrote:
> In preparation for the TAG's face-to-face meeting this week, I've
> made available the 10 May 2004 Editor's Draft of the Architecture
> Document:
>    http://www.w3.org/2001/tag/2004/webarch-20040510/
> ...
> Although the TAG has not yet agreed to these proposals,
> I welcome your comments about proposals that concern your
> issues; please send those comments to public-webarch-comments@w3.org.
> particular, please indicate whether the text as proposed satisfies you
> for that issue or
> how it might be edited to satisfy you.
> ...
> s) From the XML Schema Working Group
>     [Michael Sperberg-McQueen addressed here]
>    http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema1

The change here looks like an improvement; I'll bring it to the WG's

>    http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema4

The changes here may or may not be thought by the WG to address our
issue; I'll ask.  Reducing consistency of fragment identifiers to the
identity of secondary resources may be a brilliant solution, or may be
a brave leap from the frying pan into the fire.

>    http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema15

I think this should be OK.

>    http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema17

Deleting "that can be understood in a global context" is an
improvement, but the statement that "Namespaces in XML" provides a
mechanism for establishing a globally unique name remains false and
misleading.  The proliferation of this myth has needlessly cost some
Working Group months of their time, and the TAG should not be
propagating it.

Let me be very clear and explicit.  Nothing in the Namespaces Rec
defines, describes, provides, specifies, suggests, entails, depends 
on, or constitutes a mechanism for defining globally unique names.
The Namespaces Rec makes it possible to avoid one way in which
names assigned in isolation might fail to be globally unique, but
it neither requires that namespace owners ensure that local names
are unique within a namespace, nor mentions that as a necessary
or convenient step towards having globally unique names.  You may
have been misled by the rhetoric in the introduction to the first 
edition of the Namespaces Rec, but that introduction did not provide
an accurate characterization of the technical content of the 

>    http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema18

The diff is hard to read at this point, but I think it looks good.

>    http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema19

Thank you.

>    http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema20

I'll ask the WG.

>    http://www.w3.org/2001/tag/2003/lc1209/issues.html#schema21

>    For schema4, the Schema WG asked for a stronger statement
>    along the lines of "Don't use content negotiation", which I
>    did not add.


>    For schema21 (editorial issues), I did not address these points:
>     [3.5.1] We are surprised to not see a best practice
>             recommendation here.
>     [4.5.3] (And elsewhere) If namespace prefixes are used, there
>             should be a table indicating their bindings to URIs.
>     [4.5.6] and [4.5.8] highlight a lot of problems, but make no
>             recommendations about what to do about them.
>  t) From Michael Sperberg-McQueen
>    http://www.w3.org/2001/tag/2003/lc1209/issues.html#msm2

I believe you have identified the wrong issue; you seem to have
resolved msm1 (I am distressed to see that the references to Moby Dick
have been deleted -- otherwise, thank you), but not msm2, which
takes issues with a phrase retained in the revision.

>    http://www.w3.org/2001/tag/2003/lc1209/issues.html#msm3

I think this is an improvement; I'll need to re-read the spec in a
style less dominated by the red-green alternation of the places where
your diff program appears to have given up on its task and started
interleaving red and green text randomly.

>    I did not remove the shadow from the illustration as Michael
>    recommended.

Chartjunk does not wish for, merit, or reciprocate your mercy.  Kill

Received on Tuesday, 11 May 2004 15:01:25 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 26 January 2023 15:41:43 UTC