Up to page 15

[Patrick Durusau <patrick@durusau.net>]

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 references

103, 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 references

Correct 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 references

Correct 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 references

Correct cite: Baker, M. and P. Stark, "The 'application/xhtml+xml' Media 
Type", RFC 3236, January 2002.

99, 3294 - RFC 1847 does not appear in references

Correct 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 references

Correct 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 references

Correct 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 references

Correct 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 references

Correct 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 references

Correct 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 references

Correct 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 them

72, 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 
3.5.5.3 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, 381

I 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
patrick@durusau.net
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