Arch Doc: 18th September 2003 Editors Draft

As promised... a review of the 18th September Editors draft for Monday's
telcon. Apologies that I won't be there.

The following are in document order. If I'd had more time I'd have separated
them into high, medium and low/editorial severity... but... I didn't.

Regards

Stuart
--

1 Abstract and Introduction
---------------------------

Web as a (Hypermedia) System v Web as an Information space.

In [1] Roy offered some changes which were centred on emphasising a
definition of the web as an information space [1,2]. I like the direction
Roy was headed, and in particular the inclusion of the 1st sentence of his
draft of both the Abstract and Introduction:

(Abstract) "The World Wide Web is an information system that relates
information sources and services through the use of hypertext-style
relationships, creating a web of information that spans the Internet."

(Intro) "The World Wide Web (WWW, or simply Web) is an information system
that relates information sources and services, referred to collectively as
resources, through the use of hypertext-style relationships, creating a web
of information that spans the Internet. The Web's primary goal is to create
and maintain an efficient, scalable, shared information space that will
continue to grow indefinitely across languages, cultures, and information
mediums."

The emphasis on a web of information (or globally shared information space -
which was the tone of some earlier drafts) has been lost from the 18th
September draft and I'd like to see it restored.

[1] http://lists.w3.org/Archives/Member/tag/2003Jul/0079.html
[2] http://lists.w3.org/Archives/Public/www-tag/2003Aug/0044.html
--

More broadly, I liked the Roy's proposed intro (thought it takes a bit of
work to retrieve the specific webarch version and apply Roy's diffs to it
:-)).

--

Endnote 2 makes no sense to me at all!

--

Endnote 3 states that "other protocols than HTTP may be used to interact
with a resource identified by an "http" URI." Is that the case? Spec
reference? Also, I believe that the converse is also the case in that HTTP
may be used to interact (via a gateway?) with resources that are identified
by URI from other URI schemes than "http".

--

2 Identification and Resources
------------------------------

(picky)
2nd para: "When a representation of one resource refers to another resource
with a URI, a *link* is formed between the two resources."

I think that this gets cause and effect backward. It suggests that the act
of including a reference in a representation is what forms the link,
whereas, that the resources are linked becomes manifest by the inclusion of
references in a representation.

--

Ednote on httpRange-14: This note will need to be resolved ahead of
publication.

--

2.1 Comparing Identifiers

Good Practice: URI Characters. The short name for this 'good practice' is
awful. "Compare URI characters" or "Compare URI Character by Character"
would be better short names (although the latter may be too long).

Also, I though that Section 6 of URI gave a much fuller consideration of URI
comparison than "string comparison." as stated here.

--

2.2 URI Schemes

(picky) "Several URI schemes incorporate informations systems that pre-date
the Web into URI syntax." Would prefer "Several URI schemes incorporate
identifiers from systems that pre-date the Web into URI syntax."
Incorporating the information system itself requires more than just
incorporating the identifier space.

--
(picky)

- mailto URIs identify internet mailboxes
                       ^^^^^^^^
- ftp URIs identify files and directories accessible using the FTP protocol


--

2.4.1 Secondary Resources...

Knowledge of the media-type associated with a frag-id is implicit in the
account given here. This seems to be at odds with the use of URI references
as opaque identifiers as typified in RDF/Semantic Web. ie. we only give an
account here of the use of fragment ids in relation to a representation with
a known media-type

--

"For schemes that do specify the use of fragment identifiers..."

It is not within the gift of a URI scheme to specify the use/non-use of
fragment identifiers. They are a part of the generic URI syntax, and
defintion of the frag-id 'semantics' is delegated to media-type
specifications, not URI scheme specifications.

--

2.4.2 Fragment Identifiers and Content Negotiation

Last sentence of the 1st para to make it clear that mention of SVG here is
as an example. "Clients can do something useful with fragment identifiers if
the media format used by the representation, eg. SVG, defines fragment
identifier semantics."

2nd paragraph: The authority in the example only creates an error if the PNG
and JPEG formats are provided in addition. If across all representations
formats for a resource no frag-id semantics are defined... there is no error
- they all share the same frag-id semantics... ie. none. Also, I'm not sure
that mixing a media-type with no defined frag-id semantics is an error.

I prefer the wording of the Good practice note "Content negotiation with
fragments" from the current TR page draft [3]
[3] http://www.w3.org/TR/2003/WD-webarch-20030627/#http-conneg-frag

--

2.5.1 Retrieving a Representation

"The authority responsible for assigning a URI to a resource determines
which representations are used for interaction with the resource."

This is true but in a subtle way. On the surface it seems wrong in that a
client doing a PUT might determine what media type is used in a PUT request.
However, the server is actually has control because it can reject the
request based not only on the requested media-type but also on the validity
of the content or for any other reason it might choose.

--

2.5.2 Retrieving...

(picky)
Step 5&6 refer to "Content-type field": s/field/header/

--

2.6 Persistence and Ambiguity

In the "Moby Dick" example it occurs to me that the ambiguity that arises is
not a fault of Web architecture or URI syntax or URI scheme defintions... it
arises because the natural language description of what is identified is
woefully in adequate. It remains the case that both more precise definition
or context of use can resolve the ambiguity (wrt to a given instance of
usage).

Basically... a question that ought to be address is whether Web Architecture
allows context of use to be used to disambiguate what a given URI denotes in
that context, or whether it insists on a single denotation.

The example given ducks the question...

--

3.1 Messages in the Travel Scenario.

1st para uses the term "secondary resource" to mean something very different
from the frag-id indexed "secondary resource" of 2.4.1

This section really needs a good picture rather than the 1000 words that
elaborate what a message is in the context of the example. There really is
too much detail about the travel scenario and not enough that exposes the
structure of the messages exchanged.

--

Section 3 is woefully empty... and I could not accept a tripod with just two
legs.

--

4.1 Authorative Representation Metadata

1st pargraph is 'dripping' with "social meaning" rdfUriMeaning-39 related
phrases. 

--

4.4 Information Hiding

1st paragraph is confusing. The way the narrative develops in the 2nd
pargraph the topic really seems to be the principle of layering in systems
such subsystems (like the Xpath example) are confined within the bounds of
the relevant layer. However, the first para is confusing because it is not
clear about whether it is using the term reference in the sense of one
specification making (normative) reference to another, or in the sense of
the technology under defintion inappropriately reaching into the bowels of
some layer which has otherwise been wrapped with a carefully designed
abstraction boundary.

The 1st paragraph needs rewording and the overall intent of the section
needs to be made clearer.

--

4.5 Binary and Textual Data Formats

I wonder if some of the current discussion re text/*+xml and
application/*+xml should be reflected here. The bias in 4.5 is to promote
XML as textual data format, so perhaps some careful words are in order
around the TAG disposition wrt text/*+xml. Mayber a forward reference to
4.10.6 would cover some of this.

--

4.6 Extensibility and Versioning

Skipped pending input from Dave and Norm

--

4.7 Composition of Data formats

I think this most falls with the scope of the Extensibility and Versioning
work Dave and Norm are doing.

--

4.8 Presentation, Content and Interaction

Skipped: Replacement text expected from Chris Lilley.

--

4.9 Hyperlinks

2nd para 1st Sentence needs rewording. It has a disparaging tone. The
"however" in the middle of the 2nd sentence should be at the beginning of
that sentence.

--

4.10 XML Data Formats (and subsections)

There may be some overlap with material here and what emerges for
Extensibility and Versioning eg. use of Namespaces.

--
4.10.5 Frag-ID and ID Semantics

Re: Ednote wrt to XML Core CG suggests constrainted consideration of just an
xml:id based approach. I didn't think that was the case... I though they
were at least in principle considering a larger design space... although
they may have converged by now on a 'narrower' set of design options. Would
like to be sure that we are not implying some non-existent constraints in
the XML-Core WG

--

Received on Sunday, 21 September 2003 19:46:39 UTC