[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Up to page 15
Greetings! Just ran out of steam at page 15.There are serious errors in the citations that I will try to pick up before the meeting tomorrow.
But, starting from where I left off last time up to page 15, I have pasted my comments below.
Hope everyone is having a great week! Patrick ***********107, 3613 Is the "can" control language? That is permission? If so, can't be in note, normative.
107, 3609 Use of "may" and "must" - same question - permissions? limitations?
107, 3602 Use of "should," "shall," and "may" - same question 107, 3598 Is this meant to define "deep copy"? If so, why not:"A specific versioned copy of a versionable artifact is an explicit ”deep” copy of the content and state of a versionable artifact. A "deep" copy preserving content and state of a versionable artifact at a certain point in time.
Every "deep" copy is itself a versionable artifact, i.e. it has its own objectId. A "deep" copy has a version number, label, and check in comment.
A "deep" copy is also known as a "versioned" copy. Yes?BTW, as we discussed last week the formatting of all four notes needs to be fixed. I am posting a one note same of one way to format notes to the mailing list.
107, 3591 - Based on this definition of "representative copy" don't we need to re-visit page 115, 3925-3926?
I don't get all the optionality at page 107, 3591 from "This version is optional and implementation-dependent."
Something more like: "The state and content of a representative copy is implementation dependent." (yes?)
BTW, we need to check for implemetation dependent versus implementation-dependent. I count 7 of the latter, 1 of the former.
105, 3494 RFC 2183 - does not appear in our reference list.Citation: Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
From the editor's index at: ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt 104, 3474 - RFC 2183 does not appear in references103, 3435 - Just thought about it, do we define or invoke a definition of URL?
102, 3405, 3396, 3386 - RFC 2616 does not appear in references.Correct cite: Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Just curious, we are *not* supporting IRIs? Asking because it limits market appeal. Ah, but we do cite RFC3987, so why not use it here?
BTW, all RFC tokens are written without spaces in citation short form: RFC2616. - Need to sweep the text for those and correct.
101, 3357 - RFC 2046 does not appear in referencesCorrect cite: Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
101, 3358-3359 - RFC 2615 does not appear in references 100, 3319 - RFC 2046 does not appear in references 99, 3302 - RFC 2183 does not appear in referencesCorrect cite: Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
99, 3293 - RFC 2046 does not appear in references 99, 3294 - RFC 3236 does not appear in referencesCorrect cite: Baker, M. and P. Stark, "The 'application/xhtml+xml' Media Type", RFC 3236, January 2002.
99, 3294 - RFC 1847 does not appear in referencesCorrect cite: Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
99, 3294 - just a reminder, no "etc." 97, 3222 - MIME is specified by RFC memoranda: -> MIME is defined by: 97. 3222 RFC 2045 does not appear in referencesCorrect citation: Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
97. 3222 RFC 2046 does not appear in referencesCorrect citation: Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
97. 3222 RFC 2047 does not appear in referencesCorrect citation: Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
97. 3222 RFC 4288 does not appear in referencesCorrect citation: Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
97. 3222 RFC 4289 does not appear in referencesCorrect citation: Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
97. 3223 RFC 2049 does not appear in referencesCorrect citation: Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
97, Notes and list. I think we discussed this last time but notes should follow list items to which they apply.
95, 3152 "Altitude of coordinates" -> Altitude of location. 95, 3144 "Longitude of coordinates" -> Longtitude coordinate. 94, 3136 "Latitude of coordinates" -> Latitude coordinate.Reasoning that locations (identified by coordinates), not coordinates have altitude and that plural coordinates sounds odd with longitude/latitude singulars.
92, 3042 - 3.7.6 Location - Modeling question: Does Location require geo coordinates? Seems to and that may be a bad choice. What if geo coordinates are unknown? 91, 3011 - 3.7.5 DateTimeResolution - What calendar? Do we say elsewhere? Necessary for interchange at least.
91, 2980 - suggest "enumerates instances that establish an ordering."89, 2927 "If an addressable entity is not specified, an address must be specified." ?? conflicts with icom_core:address, Required: False
General - need to run down all must - must not, etc., to make sure they don't conflict with class/property definitions.
89, 2907, 2915 What is the relationship of icom_core:addressType and icom_core:address? I ask because icom_core:address appears to be limited to URI. So what is the function of icom_core:addressType? Or does that come into play only if EntityAddress class is extended?
89, 2900 "address defined by type and URI." - err, isn't a URI an address by definition?
83, 2677 "A relationship bondable entity is an entity which may be relationship bonded." ??
Suggest: Relationships can exist between all entities except for relationships.
A better class name would help but probably not fixable at this point. 82, 2666, 2658, 2650, "on an entity" -> "to an entity" 82, 2642 "on which" -> "to which" 81, 2602 "on entities" -> "to entities" 79, 2556 "on an entity" -> "to an entity" 79, 2548 "on which" -> "to which"77, 2474, 2457 "A category is a marker that classifies entities by taxonomy." I don't know what "marker" has to do with it? Suggest: "A category classifies entities by taxonomy."
Actually it is a stretch to say "taxonomy" since a category can exist by itself.
76, 2408 - 2414 - I don't understand the use of "marker."?? In one sense they seem to be visiable to a user and in another they are a structuring device of some sort.
74, 2369-2370 "uses several basic data type" - should enumerate them72, 2289 - So the class must have this property definition but an instance may omit the value? Should have asked before now but that sounds odd.
71, 2243 - formatting error - value "property-type" is in bold 67, 2097-2098 - I would lose the "etc." and move this sentence to a note.62, there is some formatting weirdness at the top of this page, between 188.8.131.52 Property Definitions and 3.5.6 PrivilegeEnum that doesn't show up elsewhere. Too much space.
59, 1813-1814 same formatting weirdness - need to check the style settings. I'm not a Word person but I suspect there is more than one style being applied to 3.5.4 Role. I say that because if I mouse over H3 paragraph style (for the heading), the format jumps to look almost right. Will try to look at it some more but moving onto other comments.
57, 1736-1738, 1718-1720 - "The Accessor class is a mixin class which defines the characteristics of subjects such as groups and actors that can be granted or denied access types in access control lists and privileges in role assignments."
Suggest: "The Accessor class is a mixin class that defines the access types and role assignments of groups and actors."
56, 210 "An accessor can be granted or denied access rights to access objects."
Err, no, accessor is class.Suggest: "A group or actor can be granted or denied access rights to an object."
55, 1673 - I would lose the second sentence.53, 1591-1592 - "is last modified." -> "was last modified." and delete: "This field can be set by application." (would not be much use otherwise)
52, 1582-1583 - "is created." -> "was created." and delete: "This field can be set by application." (would not be much use otherwise)
41, 1193 "affiliated company" -> "company" cardinality of "single" is perhaps too restrictive. What of contractors?
41, 1177 "affliated department" -> "department" cardinality of "single" is perhaps too restrictive. What of contractors?
41, 1173 Cardinality of single? For job title? 41, 1165 Cardinality of single? For nickname?I think 1193, 1177, 1173, 1165, as models, work for mainstream corporate America but few other places.
39, 1083 "Communities to which an actor is assigned." -> An actor's communities.
38, 1075 "Groups to which an actor is assigned." -> An actor's groups. 38, 1067 "Roles to which an actor is assigned." -> An actor's roles.36, 999 "Scopes to which a group is assigned." -> The scopes of a group. / A group's scopes.
36, 991 "Super-groups to which a group is assigned." -> A group's super-groups.
36, 983 "Roles to which a group is assigned." -> A group's roles.27, 679 "administrative realm"? Are they bringing back realms? ;-) I dont' know what this means.
25, 666-667 "The classes in Scope, Subject, and Artifact branches are defined, respectively, in Section 3.2, Section 3.3, and Section 3.4." -> "Scope, Subject, and Artifact are defined in Sections 3.2, 3.3, and 3.4, respectively."
25, 659-665 now reads: "For example, OASIS can be represented as a community with a set of spaces to represent the TC workspaces in ICOM. In the OASIS community, an organizational member can designate one person to approve the participation of its representatives in the OASIS TC’s. Once an organization’s representative is added as a member of a TC space, he or she gains the access privileges for artifacts in the space. The communities and spaces contain subjects and artifacts; however, membership of subjects in a space is administered separately from management of artifacts in the space."
Suggest delete. scope, subject and artifact, plus their interworkings are too complex for a single pargraph.
22, 551 "Date and time when entity is last modified." -> Date and time of last modification. (appears on instance of entity so no ambiguity.)
21, 510 "An entity is an object that has an immutable id and can be individually access controlled." -> An entity is an object with an immutable id and individual access control.
I assume that "individual" means there specific to the object? Not the best wording (on my rewrite) but the original seems awkward.
18, 381 - "that can be uniquely identified." ? try "...that enable unique identification." That is the characteristics defined by Identifiable are what make unique identification possible.
17, 364 - Same as 18, 381I lost steam at page 15 - There are numerous flaws in the references both errors in form as well as substance. Will try to look at those before tomorrow's call.
-- Patrick Durusau email@example.com Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau