Re: Review of 28 Nov draft

On Sunday, November 30, 2003, 5:14:01 PM, Tim wrote:


TB> On Nov 28, 2003, at 4:16 PM, Ian B. Jacobs wrote:

>> The 28 November 2003 Editor's Draft of "Architecture of
>> the World Wide Web" is now available at:
>>    http://www.w3.org/2001/tag/2003/webarch-20031128/
TB> ...
>> Complete list of changes:
>>   http://www.w3.org/2001/tag/webarch/changes#changes-20031128

TB> I'm relying the list of changes being correct in that I've used it to
TB> drive this editorial pass.

TB> 1.2.1 - Please lose the "Similarly, XML Schema" in the 2nd half of the
TB> 2nd para; the PNG/SVG example makes the point satisfactorily. Also, it
TB> is arguably not the case that XML schema's list of datatypes is 
TB> "independent".

I concur with Tim here; perhaps RelaxNG has an independent and
extensible list of datatypes, but W3C XML Schema does not (they are
subclassable, ie subject to further restriction, but not extensible.
The example is thus contentious but does not add to the clarity of the
spec and the point has already been made, and made better, with the
SVG/PNG example.

TB> 1.2.1 bullet points: 2nd bullet point, 1st sentence is really wrong, I
TB> think that what HTML actually does is to allow representations to 
TB> contain information which supplements or replaces actual HTTP headers.

Yes, it does - so on a section on what can go wrong, its a good
example, no?

Supplementing/replacing is what we say is wrong with SMIL etc when
they do it. Supplements is okay (if the absence of the information in
the header is defined as 'do what the content says' not 'enforce some
default'. Replacement is probably not okay.

Despite what the HTML 4.01 spec says
http://www.w3.org/TR/html401/struct/global.html#h-7.4.4


>> http-equiv = name [CI]
>> This attribute may be used in place of the name attribute. HTTP
>> servers use this attribute to gather information for HTTP response
>> message headers.

in practice I am not aware of a server which 'parses' HTML, looks for
meta http-equiv, and generates headers. Instead, this metadata is used
directly (eg, in the absence of headers, and in particular, to set the
encoding of a document when read from disk. This function is of course
most useful in the legacy case when the HTML is not XML and thus lacks
an XML encoding declaration.)

I am not aware of its being used for other purposes than setting the
encoding and setting a refresh interval. Its also not clear what, for
example

http-equiv="Content-Type: image/gif"

would mean in an HTML document or what exactly one is allowed to put
there.

Furthermore, even if it did, its arguable that this would be a poor
example of orthogonality; more an example of what happens when content
authoring tools and content provides can upload content to servers but
not reconfigure them.

So, in summary, the HTML meta case is a good example of
non-orthogonality ;-)  so fits in this section just fine. I agree
that the HTML spec tries to fix up the orthogonality; the fact that it
is unsuccessful is what makes it a good example.

On the other hand, the HTML spec defers entirely to the HTTP spec in
terms of what is allowed as an attribute value - which is orthogonal,
but also weakly specified, difficult to test, and would not pass CR
;-)

TB> Rest of the 2nd bullet point text is OK though.  I'd lose the 3rd 
TB> bullet point, the argument is well-established and the explanation of
TB> what's going on is not right and I don't think it's cost-effective to
TB> fix it.

On the contrary I think the explanation is correct (its used as a
client side addition/override not a server-side directive) so the
third bullet is ok for me - since the context is 'perils of
non-orthogonality' the third bullet is fine.

TB> 1.2.2

TB> Retitle it "Extensibility in General" otherwise there's no case for not
TB> moving it to 4.2.

Agreed.

[skipping typos and other minutiae that Tim points out,since a string
of 'yes fix that'* adds little value.

TB> Too many bullet points, the argument is well-made.  I'd lose 
TB> forward-compatible stylesheets and SOAP extensibility on the grounds
TB> that the fact that I personally have no understanding of either is
TB> evidence that they are less well-known in the field.

On the other hand both Ian and I do have understanding of them, and
they are good examples. I don't agree that 'what Tim Bray knows about'
is synonymous with 'what is known in the field' and am a little
surprised that you suggest this is the case.

I am happy on the other hand to agree that CSS rules for unknown
properties and property values is a good example for this context.
Further, having heard David Orchard explain it several times, i agree
that SOAP extensibility fits here too.

So I say, keep all the bullets. You have not argued that any are
wrong, just that they hit areas where you lack expertise. Since
different audiences will have different areas of expertise, I think
the longish and wide-ranging list is fine.

TB> Arguably the definition of "subset" and "extension" could live happier
TB> in 4.2 but no biggie.

Arguably, though with the re-titling you suggest they are fine here too.

TB> 1.2.3, 2nd bullet point "see XXX for related information" is leaden
TB> language; just "also see XXX".

Yes.

TB> 1.2.4 Is the 2nd sentence of the first para, about the longevity of
TB> messages, new in this draft?  It doesn't have anything to do, not in
TB> the slightest, with the actual point being made in this section.

I can sort of see a point but I agree its contentious. Some messages
may be long lived. Implying that they all are is wrong, and
unnecessary to make the point. Dropping this sentence would be fine.
Altering to "Some messages exchanged among agents in the Web may last
longer than the agents themselves" would also be fine.

TB> 1.2.4 I strongly suggest just losing the last paragraph on the grounds
TB> that it's totally opaque what it's there for.  If you know the history
TB> of this debate, it's obvious that we're throwing a bone to people like
TB> Mike Champion who argue (correctly) that APIs are actually important.
TB> But the basic point of this section is correct as it stands and 
TB> couldn't reasonably be read as saying "APIs are evil."

Well, "not in terms of APIs" is likely to be so interpreted. I thought
that the email discussion ended up concluding that message-based
interop was proven to be useful, but was not in itself sufficient and
did not mean that other approaches were wrong or flawed. So, I agree
with Tim about loosing the last para, but also suggest deleting "not
in terms of APIs or data structures or object models, but in terms of
protocols,". Make a positive point about the benefits of message based
interop, its not necessary to knock other approaches to make the
point.

TB> 2. Would anyone else like to tighten up the first para by retaining
TB> just the first and last sentences?  It would be immensely clearer I
TB> think.

The third sentence argues why global rather than local identifiers are
good, so is helpful. The second sentence adds little, I agree.


TB> 2.4 last para isn't quite there, you need to reword slightly: "even if
TB> an agent cannot handle representation data in an unknown format, it can
TB> still retrieve the data, which may contain enough information to allow
TB> a user or..."

Yeah, that is clearer.

TB> 2.7.2 that's an "Assertion" not an "Expression", right?

Yep.

TB> 3.1 first numbered step, shouldn't that be xlink:href rather than 
TB> "XLink href"?  In particular since you use that in step 2 :)

See my earlier mail.

TB> 3.2 1st para, shouldn't "metadata about the data" be "metadata about
TB> the resource"?

Some is about the resource, some is specific to a particular resource
representation.

TB> 3.4.1 2nd bullet, the terminology "namespace of the root element" only
TB> applies in the case of XML representations, it *may* be worth 
TB> acknowledging that

Probably, but not crucial I think.


TB> 3.4.1 I agree with Ian that the trailing good practice is now pure
TB> fluff and should be deleted.

I'm not so sure. Although "Server managers MUST ensure that resource
metadata is appropriate for each representation." might make a better
point.

----8<---- Chris got to here before TAG telcon --------

TB> 3.5 Why the new XForms plug?  It adds nothing to the example and 
TB> creates confusion because people are going to wonder if this is special
TB> and different and couldn't have been done with old-fashioned HTML 
TB> forms.  Must be removed.

TB> 3.6.2 First sentence hosed.

TB> 3.7.  Blecch, I hate this section but can live with it.  Except for,
TB> what in flaming hell is MLDonkey and how did it suddenly parachute in
TB> here?

TB> 4.1 Why don't we just lose the note about "text" and "text/" here, it's
TB> covered below I think.

TB> 4.2.1 Moving the namespace-versioning stuff from 4.6 is OK, but I think
TB> you need a new section break in front of the story, you switch abruptly
TB> from version information to this very xml specific stuff.  Shouldn't
TB> cause any problems putting in.

TB> 4.2.2 "must understand".  I totally don't agree that "must understand"
TB> is limited to markup from another namespace.  XHTML could for example
TB> have applied a "must understand" policy to new XHTML elements (they may
TB> have, for all I know).  All you need to do is /markup from an 
TB> unrecognized namespace/unrecognized markup/

TB> 4.3 The para beginning "Note that when content, presentation, and 
TB> interaction are separated" is *very* fuzzy and I think could just be
TB> nuked.  I don't remember discussing this, is it the output of TAG 
TB> discussion?

TB> 4.4.1 s/see the "base" element in HTML and XML/see the "base" element
TB> in HTML and the "xml:base" element provided by XML/

TB> BTW 4.4 is *much* better

TB> 4.5.1 s/in an in-order/in in-order/

TB> 4.5.1 clean up commas in 2nd sentence 1st clause, either 0 or 2, not 1.

TB> 4.5.2 is the TAG comfy with being this much in favor of XPointer?  I'd
TB> need to hear a few explicit "YESes"

TB> 4.5.5 2nd para, 2nd sentence is COMPLETELY WRONG.  Yes, you can convert
TB> back & forth between qunames & URI/local-part pairs.  What you can't do
TB> is go back & forth from qnames to URIs; which is clearly what Norm
TB> meant.

TB> 4.6 could be lost without loss of value




-- 
 Chris                            mailto:chris@w3.org

Received on Monday, 1 December 2003 14:51:26 UTC