104 lines
7.5 KiB
Plaintext
104 lines
7.5 KiB
Plaintext
%META:TOPICINFO{author="RicardoPereira" date="1147258644" format="1.1" version="1.4"}%
|
|
%META:TOPICPARENT{name="TipDocuments"}%
|
|
---++ Walter Berendsohn
|
|
|
|
a) Formal change: use a b c d in bullets where those are not in line with the numbering of the heading (e.g. 3.0.1).
|
|
|
|
b) The point made in 12 should be made somewhere earlier. I had the following points noted down as not really applying to collections of standard data and/or services providing standard data, before I read the last point.
|
|
|
|
3.1 4.0.1. 4.1.1. 4.1.1.1. (!) 4.8. 4.10.1.
|
|
|
|
I am still not sure what will be the standard in the case of a service serving, e.g., Author name abbreviations? The actual current state which must be cited with a retrieval date?
|
|
|
|
---+++ Response: Roger Hyam
|
|
|
|
a) Good point. I have gone through and changed the numbers to letters. Makes things much clearer.
|
|
|
|
b) This is true but I am reluctant to change the ordering of the main sections now as people are commenting on the different sections and if we change the ordering it will cause more confusion that clarity. I think we will quite quickly need an administrative standard to describe how to publish a 'data standard' and expand on this point.
|
|
|
|
---++ Neil Thomson
|
|
|
|
4.5/6 - Very glad to see this, not least for digital sustainability reasons. However, I am unsure of the status of PDF as an open standard.
|
|
|
|
4.7 - I doubt that the Europeans will like an insistence on US English very much!
|
|
|
|
4.11.1.3 - Surely this requires more than one separately developed implementations? I must read the Wikpedia entry!
|
|
|
|
Appendix A: A list of Emerging Standards (e.g. NCD, taXMLit, TaxonX etc.) would be valuable.
|
|
|
|
---+++ Response: Roger Hyam
|
|
|
|
The file formats standard will specify file formats in detail. This will be a standard and so can be updated through time. I believe PDF does count as an open standard as it has a published specification. I would currently favour XHTML and am working on a prioritized list of formats. This will all come up for review.
|
|
|
|
See my response to Jessie below re US English. Only non-US native English speakers have commented so far!
|
|
|
|
Not sure how the sentence about reference implementations got mangled. It should say "Multiple reference implementations can demonstrate the independence of the standard from an implementation." I will change the document.
|
|
|
|
I might be good to have a list of emergent standards but this is probably best left to the forth comming collaboration environment as the list will be fairly dynamic.
|
|
|
|
|
|
---++ Jessie Kennedy
|
|
|
|
I was surprised that we have to use US English and would've thought English would've been ok - but maybe that's just me not wanting to have to keep changing my dictionary - and of course what must the other nations feel.....
|
|
|
|
---+++ Response: Roger Hyam
|
|
I am afraid the US English was my proposal. There needs to be a single language for normative documents so we don't get into arguments about interpretation between different languages. English is the current _lingua franca_ of science so that has to be the choice. The next choice is which version of English and I chose the one that wasn't my own and that software tends to default to! Choosing one dialect of English reduces possible disputes over gramatical construction and spelling. It would have been nice to use the Queen's English though :)
|
|
|
|
---+++ Response: Walter Berendsohn
|
|
Well, in some respects British English is easier for non-native speakers - e.g. with respect to -ize and -ise. I agree with Jessie that it should be left to the document's editor. In the case of our overlapping XML schemas, however, it would be good not to have different spellings for element names.
|
|
|
|
-- Main.JessieKennedy - 17 Jan 2006
|
|
I can understand English being the standard but I'm not convinced that we need to specify either US or UK or any other version for that matter - I think we can all deal with either as we tend not to use local dialects when writing formal text and I don't believe we're relying on machine readable English for any of our tasks. The decision was commented on 3 of the respondents....
|
|
|
|
---++ Arthur Chapman
|
|
|
|
1. In the Recommendations, I think there separate Recommendation on the consistent naming of TDWG Standards. It is mentioned under 4.9.1, but this is a very important issue that I believe needs separating out. We obviously need to develop a naming convention/standard.
|
|
|
|
2. Another recommendation: I sent Lee some time back an example of a pseudo-standards organisation that included in its documentation a section on "Who the standard is aimed at". I can't find that reference at the moment. "Museum Curators" etc. I think this is a very good idea and would recommend it in the documentation as a mandatory.
|
|
|
|
3. Recommendation 4.6.2. Why "US English"? I think you need to add some justification in your justification statement.
|
|
|
|
4. Recommendation 4.9.5. I think it is worth also including here "How the Standard should be cited" It is often very difficult to find out how to cite /reference a particular standard (and books sometimes). It is easily solved by adding a one line "This Standard is to be cited as: ...." near the Copyright statement.
|
|
|
|
5. Appendix A: [Missing Hispid 4 and Botanical Periodicals now searchable].
|
|
|
|
---+++ Response: Roger Hyam
|
|
|
|
1. I think you have a good point on naming here. What I will do when drafting the file formats document is flag that it should perhaps be in a different standard and see what comes out of the review of that. I have no objection to it being raised to the level of a standard in its own right if needed. There is discussion concerning namespace and schema locations that are related to this at the moment.
|
|
|
|
2. I think that target audience should be covered by the motivations section of the standard. I will bear this in mind as I draft the spec for it.
|
|
|
|
3. See the comment in response to Jessie.
|
|
|
|
4. I will add this to the document specifications.
|
|
|
|
5. I left these out as they are not proposed TDWG standards - though perhaps they will be when we have the mechanisms in place.
|
|
|
|
---++ Nozomi Ytow
|
|
|
|
In "Documentation and Supporting software Strategy for TDWG", 4.3
|
|
recommends to attach copyright and IPR statements. Because standard
|
|
itself, e.g. XML schema, is also a part of the document by
|
|
recommendation 4.1, it implies that standard itself is also covered
|
|
by copyright or IPR. Covering a standard by copyright could be cause
|
|
of difficulty for users to use the standard. For example, ISO
|
|
copyrihgt page http://www.iso.org/iso/en/xsite/copyright.html says:
|
|
|
|
Any use of the material, including reproduction in whole or in part to
|
|
another Internet site, requires permission in writing from ISO.
|
|
|
|
It looks like that we need to require ISO's persmission even to use
|
|
things written in ISO document inlcuding standeard itself. It is
|
|
ridiculous; standards are there to be used. We need clarification
|
|
that we do not intend such restrictive copyright/IPR at least for the
|
|
standard itself. Mentioning on e.g. W3C style copyright could ease
|
|
readers. Recommendation A.4 in "Existing TDWG Processes" may be
|
|
sufficient.
|
|
|
|
---+++ Response: Roger Hyam
|
|
|
|
I am not a copyright expert but looking at the models used by other organisations it is necessary to attach copyright that allows unrestricted use of the standard as the standard and assures that the original authors are quoted. If no copyright statement is attached then the copyright would remain that of the author and they may choose to withdraw it from some point - effectively preventing circulation of a standard. This will be dealt with in more detail in the Copyright and IPR document on which I hope we will get advice.
|
|
|
|
|
|
|
|
-- Main.RogerHyam - 06 Jan 2006 |