[To save time, I'm copying this to the list]
John made the mistake of asking me to do a final check of the RFC#1 draft.
It was a mistake, because it has caused me to come up with some further nits
:-)
Section 3 starts with:
> 3. Description of Dublin Core Elements
>
> The following is the reference definition of the Dublin Core Metadata
> Element Set. The evolving reference description, including any defined
> qualifiers, resides at [2]:
>
> http://purl.org/metadata/dublin_core
>
> Note that elements have a descriptive name intended to convey a common
> semantic understanding of the element. To promote global interoperability,
> a number of the element descriptions suggest a controlled vocabulary for the
> respective element values. It is assumed that other controlled vocabularies
> will be developed for interoperability within certain local domains.
>
> Each element is optional and repeatable. Furthermore, metadata elements may
> appear in any order, and with no significance being attached to that order.
>
> In the element descriptions below, a formal single-word label is specified
> to make the syntactic specification of elements simpler for encoding schemes.
> Although some environments, such as HTML, are not case-sensitive, it is
> recommended best practice always to adhere to the case conventions in the
> element names given below to avoid conflicts in the event that the metadata
> is subsequently extracted or converted to a case-sensitive environment, such
> as XML (Extensible Markup Language) [3]. A metadata element's meaning is
> unaffected by whether or not the element is embedded in the resource that
> it describes.
I'm unhappy with the structure (as opposed to the content) of the last three
paragraphs above and suggest a re-arrangement.
Disregarding the positions of para breaks, the logical chunks of text we
have are:
A:
> Note that elements have a descriptive name intended to convey a common
> semantic understanding of the element.
B:
> To promote global interoperability,
> a number of the element descriptions suggest a controlled vocabulary for the
> respective element values. It is assumed that other controlled vocabularies
> will be developed for interoperability within certain local domains.
C:
> Each element is optional and repeatable. Furthermore, metadata elements may
> appear in any order, and with no significance being attached to that order.
D:
> In the element descriptions below, a formal single-word label is specified
> to make the syntactic specification of elements simpler for encoding schemes.
E:
> Although some environments, such as HTML, are not case-sensitive, it is
> recommended best practice always to adhere to the case conventions in the
> element names given below to avoid conflicts in the event that the metadata
> is subsequently extracted or converted to a case-sensitive environment, such
> as XML (Extensible Markup Language) [3].
F:
> A metadata element's meaning is
> unaffected by whether or not the element is embedded in the resource that
> it describes.
I suggest we combine A and D as follows:
In the element descriptions below, each element has a descriptive name
intended to convey a common semantic understanding of the element, as well
as a formal single-word label intended to make the syntactic specification
of elements simpler for encoding schemes.
and follow them with the remaining chunks in the following order, with para
breaks as shown:
Although some environments, such as HTML, are not case-sensitive, it is
recommended best practice always to adhere to the case conventions in the
element names given below to avoid conflicts in the event that the
metadata is subsequently extracted or converted to a case-sensitive
environment, such as XML (Extensible Markup Language) [3].
Each element is optional and repeatable. Furthermore, metadata elements
may appear in any order, and with no significance being attached to that
order.
To promote global interoperability, a number of the element descriptions
suggest a controlled vocabulary for the respective element values. It is
assumed that other controlled vocabularies will be developed for
interoperability within certain local domains.
A metadata element's meaning is unaffected by whether or not the element
is embedded in the resource that it describes.
Finally, a suggested change of content. We currently say, above, that:
Although some environments, such as HTML, are not case-sensitive, it is
recommended best practice always to adhere to the case conventions in the
element names given below to avoid conflicts in the event that the
^^^^^
This should be:
Although some environments, such as HTML, are not case-sensitive, it is
recommended best practice always to adhere to the case conventions in the
element labels given below to avoid conflicts in the event that the
^^^^^^
should it not?
Oh dear! Now I've made the mistake of asking Charles to do a final check of
the RFC#1 draft. It was a mistake, because it has caused him to come up
with some further nits :-)
Section 3 ends with:
> The metadata elements fall into three groups which roughly indicate the
> class or scope of information stored in them: (1) elements related mainly
> to the resource when viewed as Intellectual Property, (2) elements related
> mainly to the Content of the resource, and (3) elements related mainly
> to the Instantiation of the resource.
>
> Content Intellectual Property Instantiation
> ----------- --------------------- -------------
> Title Creator Date
> ... ... ...
Charles complains that the columns are in the order: 2, 1, 3. He suggests
we re-arrange the columns or re-arrange the introductory sentence.
Section 3.9 says:
> 3.9. Format Label: "Format"
>
> The data format of the resource, used to identify the software
> and possibly hardware that might be needed to display or operate
> the resource. For the sake of interoperability, Format should be
> selected from an enumerated list that is currently under development
> in the workshop series.
Charles suggests the word "on" between "operate" and "the resource".
Finally, Charles suggests that all TABs be replaced with the appropriate
numbers of SPACEs, as the rendering of TABs is device dependent. The
relevant RFC [1] doesn't actually forbid TABs, but it does not use them
itself.
[1] "Instructions to RFC Authors", http://ds.internic.net/rfc/rfc2223.txt
----------------------------------------------------------------------------
Misha Wolf Email: [log in to unmask] 85 Fleet Street
Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ
Reuters Limited Fax : +44 171 542 8314 UK
----------------------------------------------------------------------------
12th International Unicode Conference, 8-10 Apr 1998, Tokyo, www.unicode.org
7th World Wide Web Conference, 14-18 Apr 1998, Brisbane, www7.conf.au
------------------------------------------------------------------------
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Reuters Ltd.
|