Comments for CR-xml-fragment-20010212

These are just a few comments on your XML Fragment Interchange
Candidate Recommendation [1]. It accomplishes so much in so little
space it is a pleasure to read.

You might consider cutting the change notes when and if you go to
Recommendation, to simplify even more.

The URIs for previous versions would be more readable if they were
newline-delimited rather than space-delimited.

Globally, Docbook -> DocBook and aka -> a.k.a.

ACME.COM is a registered domain. W3C recommends using IANA's
example.com, example.net, and example.org for examples. Please see RFC
2606 section 3 at http://www.ietf.org/rfc/rfc2606.txt.

The beginnings of the Abstract and Overview seem to be copied from
OASIS TR 9601:1996 (http://www.oasis-open.org/html/tr9601.html). I
didn't look any farther. You might credit them, or reword any text that
wasn't W3C's originally. It may be that Paul Grosso has some copyright
in OASIS's TR; I don't know.

In the Overview par. 3, the long section in parentheses about
send/receive could be cut, as these terms are defined in section 3
using exactly the same words.

Same with these two sentences that appear more or less identically in
both sections 1 and 2. I would cut one set.
     The goal of this activity is to define a way to enable processing
     of small parts of an XML document without having to process
     everything up to the part in question. This can be done
     regardless of whether the parts are entities or not, and the
     parts can either be viewed immediately or accumulated for later
     use, assembly, or other processing.

The abbreviation fcs is defined in section 3 in lowercase. Twice in 5.1
and sometimes in section 5.2 it is capitalized FCS. Could you choose
one or the other? (Lowercase with or without <code> markup is fine.)

Below, a section and paragraph number is followed by a quote and then
a suggestion.

1. par. 3
is call the fragment entity
is called the fragment entity

2. last par. is one really long sentence. Could break at the semicolon.

3. par. 1
for the purposed of
for the purposes of

5.1 par. after second Note
comes from Fragment Interchange namespace
comes from the Fragment Interchange namespace

5.1 last par. and 5.4 par. 2
arabic numbers
Arabic numerals

web server (twice)
Web server

5.1 second example
arabic
Arabic

5.2 first constraint
Fragment Interchange Namespace URI
Fragment Interchange namespace URI

5.2 definition
fragment Interchange namespace
Fragment Interchange namespace

5.4 par. 2
web server
Web server

5.4.1 last par.
for the purposes of completeness of this example
for the purpose of completeness in this example

In A.2. MIME and RFC 2387, is there a reason for linking to imc.org
rather than to ietf.org or rfc-editor.org?

C.2 external entity
Base 64
base64

[1] http://www.w3.org/TR/2001/CR-xml-fragment-20010212

Best wishes for your project,

-- 
Susan Lesch - mailto:lesch@w3.org  tel:+1.858.483.4819
World Wide Web Consortium (W3C) - http://www.w3.org/

Received on Wednesday, 18 April 2001 21:15:25 UTC