[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [icom] Reviewer comments addressed in CSPRD 03
Eric,First, apologies for my sudden silence. My wife had knee replacement surgery, which was planned in advance, but I forgot to tell you and other members of the TC of my impending lack of attention to the TC. Sorry.
Second, thanks for your attention to the comments and I am reviewing your responses now.
Third, I have a specific comment on the cardinality and RFC issues below. On 02/28/2012 02:26 PM, Eric Chan wrote:
Your example suggests that ICOM is compelling particular requirements for modelling affiliations. Yes? What if all I know about Laura is that works for DERI and IRED (a small start-up) where I have complete information on DERI and just the name, IRED, on the other.Most of the reviewer comments were incorporated in CSPRD 03 (see the changes tracked in http://www.oasis-open.org/committees/document.php?document_id=45306&wg_abbrev=icom). 1. To address some of the required changes in the comments, we defined a mixin class and enumeration class in pairs. For example, CardinalityEnum is an enumeration which specializes the Cardinality class. ICOM follows CMIS grammar for cardinality, which supports single and multi. Implementations can extend ICOM by defining a cardinality instance to support 1..N or 0..N. (Patrick and Peter commented about this). 2. Patrick and Laura commented about supporting multi cardinality for nickname, title, profession, company, etc. properties of a person or contact. However, changing the cardinality of these properties will not provide the desired functionality. For example, a person who has two affiliations, will need multiple tuples (title-1, profession-1, company-1) and (title-2, profession-2, company-2). This will need more than specifying multi cardinality for each property. The applications can use metadata model to extend the properties to define tuples for affiliations. For this reason, I did not change the cardinality for these properties in CSPRD 03.
If all I want to record is IRED and no more, why should ICOM compell extension for such a common case? Lots of data is incomplete.
3. Patrick commented about adding each RFC we reference in the text to the normative or non-normative references list. We had included major RFC's in the reference lists. The RFC's we named in the text are fine-grained (some are supplement to major RFC's). They may dilute the major RFC's that we want to highlight in the references. Another concern is that the RFC we named in the text comprise only a partial list so could be misleading to formally list these RFC's and exclude other potentially relevant RFC's. For this reason, I did not add these supplemental RFC's to the references list.
I think we have a different understanding of the role of references.A "normative" reference isn't an "important" reference. It is a reference to which conformance is *required* in order to conform to the standard.
For example, when ODF cites XML 1.0 as a *normative* reference, that means that if you don't conform to XML 1.0, you cannot by definition conform to the ODF standard.
That is why normative references are so necessary to get right in a standard. Any normative reference and usually those are made more specific in the document, requires *additional* effort on the part of implementers.
A "non-normative" reference is a reference, usually not to a standard but it can be, that will help implementers understand some requirement or statement in the standard.
For example, for an XML based standard that involved queries, I might have a non-normative reference to XSLT 2.0 and XPath 2.0 by Michael Kay. And later I could have references to specific parts of that work that illustrate some principle that I am discussing in the standard. But no one would be required to *implement* Michael Kay's explanation. It is cited simply as an aid to understanding. What they are required to implement is the standard and to conform to any normative references.
Perhaps that is the better distinction:Standard + normative references -> implementers implement the standard, in conformance with any normative references (think of them as specification of additional requirements for conformance)
Standard + non-normative references -> implementers use non-normative references to aid in understanding the standard, the standard being what they implement.
Does that help?I appreciate your raising the issue because that is a better explanation (I think) than I have made in the past.
Hope you are having a great day! Patrick
Regards,
Eric
PS.
Peter's comments include
Relating metadata model to ISO/IEC 11179.
Cardinality should support 0..N or 1..N besides single and Multi
(see http://schemas.stylusstudio.com/ubl/n9877e500/element_Cardinality.html)
Laura's comments in http://wiki.oasis-open.org/icom/DraftSpecComments (which also includes Patrick's comments).
Patrick's comments in context below:
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.
=====================================================================
203, 7047-7050, I would delete: "to express that" and leave "a conference session ended after the host left" and similar revisions on the following lines.
*****
203, 7046, "There are four conference session states defined by ICOM" -> ICOM defines four conference session states: (voice)
[correction of my correction (see below "conflict with line 6926" -> Should read: "The ConferenceSessionEndingReason class defines four conference session states:"
Avoids the conflict with line 6926 (which also needs to be re-written) and probably need a note here about conference sessions, which applications may manage together.
Insert After line 7018: "Note: Other conference session states are defined by the ConferenceState class 4.11.3"
Is there some reason for two conference state classes? No real preference, just seems cleaner to have all session information together.
There are approximately 157 occurrences of "defined by" and 32 instances of "defined by ICOM"
I suggest the 32 cases of "defined by ICOM" certainly be changed and the remaining 125 be considered on a case by case basis.
(I will not be commenting on these cases individually.)
Trying to resolve the next problem made me realize that "...four conference session states..." is incorrect. (now corrected my comments)
There has to be a conference state for "ongoing," yes?
Ah, *conflict with line 6926* - "There are five conference session states defined by ICOM:" (This is the only session state conflict.)
202, 7040-7041, "An enumeration of the instances each of which expresses a reason for ending a conference session."
Err, but icom_conf:Hibernating does not record the end of a conference session - yes?
Suggest: "Value: Defines reasons for ending conference."
I am not real sure about "hibernating" = ending.
202, 7022, "The ConferenceSessionEndingReason class is defined by the attribute values:"
Let's make my comment at 203, 7056, general to all 123 instances of "is defined by" and change to "has the attribute values"
202, 7020-7021 "The ConferenceSessionEndingReason class is an enum class that enumerates the instances each of which expresses a reason for ending a conference session." If it enumerates, doesn't that already mean it is an enum class?
Try: "The ConferenceSessionEndingReason class enumerates values which specify the reason for ending a conference session."
202, 7016-7017 "...which are implementation-defined." 73 times.
Do we mean to restrict what may define additional properties? That is only implementation-defined or can other profiles/standards define additional values for ICOM classes? Thus: "The ConferenceSession class MAY include additional property definitions." (we would need a note somewhere about this meaning.)
201, 7001 Address of a server that hosts a conference session. -> Address of the server that hosts a conference session.
BTW, property type string?
199, 6919, "An enumeration of the instances each of which expresses a session state of a conference." -> Session state of a conference.
198, 6867-6869 "The ConferenceType class is an enum class that enumerates the instances each of which expresses a type of a conference".
Again the enum class that enumerates, try: The ConferenceType class enumerates the values that specify a type of conference.
To return to 199, 6892-6896 - the conference types, are these valuable/useful? Just curious. Why not just have string?
198, I don't have a line number, the class image. Can we link the boxes to the class definitions in the document? Just curious.
197, 6843, 6852 - How would I distinguish between a current or future start/end time?
196, "The Conference class inherits property definitions from super classes." - Err, doesn't that seem a big vague? Which super classes? 72 instances, I won't comment on them separately.
Not sure it is necessary b/c at the super classes we can say: x, y, z subclasses inherit from B superclass. Yes? Easier than re-writing that line.
195, 6769, "A conference is a *folder that represents a durable context* for conference sessions."
In what sense a "folder?" And what is "durable context?" Do we define that?
I think what is meant is:
The Conference class is an extension of icom_core:Folder and defines the attributes and values associated with a conference. (or something like that)
I would drop: 195, 6770 "It contains conference metadata, settings, and transcripts." Not specific enough to be helpful. Lots of other things could be said there.
195, 6756 "enumeration of the instances" 24x instances. try -> Defines values reflecting the status of an announcement. (and correct all the others as well)
195, 6746 - This happens elsewhere but why do we have extendsFrom with a blank Value: ? Is that informative?
193 6700-6701 "An announcement is a special topic for discussions that are valid for a specified period of time."
The way this reads, the "discussions" are valid for "a specified period of time." Not sure that is correct. An announcement might have no expiration. - All staff much change ICOM logins every 6 months, with 16 character passwords and 24 character user names. ;-)
Besides, isn't the "description" here of the class? Not its possible content?
Try: Defines values for read only messages with activation and possible expiration times.
193, 6682-6683 - try: An announcement is a read only message that may have an expiration time. (Don't you think activiation is implied by the message being sent? Or is that separate?)
192, 6646 "A topic is a folder that contains discussion threads."
But under 4.10.6.2 Class Definition (192, 6630) we are talking about "topic" as a class.
I may be seriously mistaken but the text seems to be mixing classes and implementation details, such as folders.
192, 6628-6629 - same issue, now calling "topic" a folder. Part of the problem is name overloading between classes and implementation details, such as folders.
BTW, limiting sorting to chronological order or threaded by reply is ok but why not add subject?
191, 6584 - folder? is forum a class or a folder?
If class -> The folder class defines values for sub-forums, topics and announcements.
(Note, no "," before the and.)
190, 6567 - folder?
189, 6543-6544 "TopicContainer is a mixin class *which* defines the characteristics of entities that contain Topics." -> TopicContainer is a mixin class *that* defines the characteristics of entities that contain Topics.
188, 6527 - same as 189, 6543
187, 6464 - same as 189, 6543
What the hell, generalize "is a mixin class which defines the" to "is a mixin class that defines the" for all 24 instances.
186, 6447 "...defines the characteristics of entities that contain..." What happened to folders? I don't like "folders" but let's be consistent.
186, 6445 "A discussion container is a container of discussions."
?? Can't define something in terms of itself, even using the plural form. ;-)
Try: "The DiscussionContainer class defines properties of containers for discussion items."
Yes?
186, 6423-6324 "Discussion is a mixin class which defines the characteristics of entities that can be placed in a DiscussionContainer."
But if DiscussionContainer is a class, no entities can be placed in it.
Perhaps: "...that can be placed in containers defined by the DiscussionContainer class."
???
185, 6406-6407 - same issue as 186, 6423-6424 (except what are elements?) 14x on elements, 48x on entities - need to check for consistency
185, 6395-6396, 6397-6399, "etc." has no place in normative language. Either we define what is meant, or we don't. Can't leave people to guess.
happens 8x - let's clear all of them. Either re-write to insert complete references or remove the listing as incomplete.
184, 6358 - "There are eight task participant¡¯s status defined by ICOM:" in addition to the usual re-write, "the relationship of a partcipant to a task has eight possible statuses" Or something like that - may need to discuss.
184, 6365 - "...as assignee is tenative about a task status." Do we mean tenative about a task? Being tenative about "task status" sounds like the excuses that managers get all the time. ;-)
178, 6140 artifact? artifact, 139x - so far, folders, entties, artifacts (Ah! You are using the icom_core classes to say "artifact" etc. Not all that transparent. In some sense they are all class extensions as well, but you would not say: An occurrence is a class extension that represents an event in a calendar. (the place where I realized where you were getting artifact, etc.))
177, 6094 "folder" is back
174, 6002, free busy interval or FreeBusyInterval?
174, 6004-6005, passive voice, suggest: "If a free busy type is icom_cal:Busy, then a time interval is not free for scheduling."
174, 5993 "A list of participants whose free busy intervals are merged." -> "A list of participants."
They are *not* participants b/c their free busy intervals have been merged.
In fact, this is the only use of "merged" so that means we failed to define this elsewhere. Yes?
I suspect that should have been under 172, 5932 FreeBusy Module. Yes?
168, 5749 and 5751 to explress cancellation/confirmation of an occurrence or occurrence series. (voice)
166, 5695 "Participant transparency..." I searched our document without finding a definition. Does this means transparency in the sense of RFC 2445? Seems like we should be a bit clearer about that point.
164, 5614 icom_cal:exceptionToOccurrenceSeries - I understand this means an exception to some occurrence series but what does that mean? What are its semantics? Does it mean it has different properties than other occurrences in the series? If so, which ones? All? Then how is an exception any different from simply having a unique occurrence declared outside of any occurrence series?
164, 5599 "An occurrence series that includes an occurrence." ?? Do we mean "...that includes multiple occurrences." ?? But why else have a series? Or do you want to have 1...n for any series?
164, 5602 btw, it would be helpful if the Property Type: values were hyperlinks.
Mostly because I can't search for icom_cal:OccurrenceSeries as a string. Why? b/c we define the class icom_cal and then define the class under it, OccurrenceSeries, which differs from icom_cal:occurrenceSeries only in capitalization of the "o" in occurrence. Clever but not terribly helpful.
Remember, we don't want people to memorize the document to use it.
160, 5478 - "An attendee of an occurrence series." Can attend an occurrence but not sure about being an attendee of a series. Isn't attendance per occurrence?
160, 5470-5471 "One or more simple content attachments in an occurrence series." Delete "simple" unless that has some significance.
159, 5430 Participants *of* an occurrence series. of -> in ?
157, 5354 "is an artifact" extension of icom_core:Artifact - After thinking about it some more, suggest just say series is a class instance for all these cases because the type of object (in the implementation sense) is really up to the implementation. It is no more an artifact that earlier things were folders. They are extensions of those classes. Not the same thing.
157, 5342 "Recurrence elements of a calendar" Do we mean elements -> entries? Or does elements have a broader meaning?
156, 5326 "Time zone of a calendar." Calendars don't "have" time zones. I prefer "Time zone setting for a calendar. That is a time zone is separate from a calendar.
156, 5316-5317 (here we start to trip up with the folder/artifact, etc) "A calendar is a folder that contains time management artifacts such as occurrences and occurrence series." Is that all it can contain? Or we giving an example in normative language? Let's take out "such as" and reform the language on folder/artifacts.
BTW, there are 23 "such as" cases. Let's resolve all of them.
153, 5195 "simple content attachments" -> "content attachments" (unless "simple" in this context has special meaning)
152, 5187 "Time zone of a person." ?? Ah, "A person's time zone." Yes?
152, 5179 "A person which is bookmarked by a contact." Questions: Is this a property that indicates a person's record has been bookmarked? if so, try: "PersonContact class instance has a bookmark." I am guessing on this one. There are semantics of some implementation that aren't clear. Such as how does a contact bookmark a person? Or is there some other mechanism? Or none at all?
151, 5130 "Sub-address books in an address book." OK, so where is the address book? addressBook -> sub-addressBooks. All I see is the latter.
151, 5122 btw, 5130 conflicts with 5122 - An address book is a folder that *contains addressable contacts.* NOT sub-address books in an address book. Yes?
150, 5089 - just a reminder about "defined by..."
148, 5012 "what a presentity is" ? I have no idea. but mis-spelled. perhaps "An activity object describes an activity." ???
147, 4995 - same as 148, 5012
145, 4974-4975 - "a reachability status of a contact method."
At page 97, we define: PersonContact to include: "It can also contain addresses, phone numbers, and other entries about an external person."
So, how is any system going to display reachability information for an address?
Jumping ahead a bit but remind me to ask about Presence - why doesn't it use contact information from elsewhere? and actitives from calendar?
145, 4946 - "A note about a contact method in a presence." ?? That sounds like a note about an address or other contact.
145, 4938 - See 145, 4974-4975 same issue
144, 4921 presentity - ok, I got curious, 35 times. Let's kill them all.
143, 4888 "describes reachability *circumstances* of a..." And what are those?
143, 4864-4865 - see comments about contact information - isn't this duplication?
139, 4766 "It includes a list of the activities describing what a presentity is doing." Assuming better spelling: "It is includes a list of activities for XXX." It cannot be describing what XXX is presently doing, it can only list what XXX is supposed to be doing. Not the same thing.
139, 4743 Note to be propagated to an -> Note propagated by an associated...
139, 4735 Priority to be propagated to an -> Priority propagated by an associated... (now if I just knew what a priority was)
138, 4726-4727 "Reachability status to be propagated to an associated contact method." -> Reachability status propagated by an associated contact method.
138, 4692-4693 "An instant message connection contains the queues for inbound and outbound instant messages." -> An instant message connection contains queues for inbound and outbound instant messages.
137, 4673 "An instant message connection contains the queues for inbound and outbound instant messages." -> An instant message connection contains queues for inbound and outbound instant messages.
136, 4661 "A queue for outbound instant messages." Needs a reference to the inbound queue See page 139, line 4750
135, 4612 "...enumeration of the instances...? see earlier comments on value listings
134, 4578-4589 - drop "to express that an" and just "Instant message is..."
132, 4523 "A formatting style of rich text message in xhtml." -> Text message in xhmtl.
131, 4498 -> A list of participants to receive a message.
131, 4488-4489 "..is a special type of message for one-on-one,..." but at line 4498, we have a list of participants. Not really one-on-one.
129, 4458-4460 - to express - reform
128, 4425-4428 - to express - reform
128, 4419 - enumeration - reform
128, 4389-4396 - to express - reform
127, 4382 - enumeration - reform
127, 4350-4358 - to express - reform
126, 4342 - enumeration - reform
124, 4244-4248 - "..and other custom headers."? What am I required to handle? What is a "printable header string?" What are ascii and non-ascii strings? This seems underdefined.
124, 4235 - how is "delivered" and editable mode? Just curious.
123, 4209 - is requested -> requested
123, 4184-4185 -> as defined in RFC 2183 specifies a presentation style
122, 4174-4176 additional...including....etc. - Sorry, either we state the normative requirements or we leave them alone.
122, 4157 -> A list of participants to receive reply messages.
122, 4148 -> to receive blind-carbon-copies of a message.
122, 4139 -> to receive carbon-copies of a message.
121, 4231 -> to receive a message.
121, 4122 envelop -> envelope delete (sometimes called return path)
add: Note: Evelope sender is aslo known as return path.
121, 4112 "special type of message..." special how?
121, 4092-4095 is a type of -> is a...
121, 4092 that is delivered -> delivered
120, 4089 - special? how?
120, 4070 -> When a recipient receives a message. (time is only part of when, date counts as well)
119, 4031-4033 why do we have this note? What does name "holds the subject of a message" mean? For a phone call for example.
117, 3980 a "rendered page and a rendered content." ?? I don't know what either of these mean or even why we have this. Pages or objects can't be rendered until displayed and if we are talking about stored, they aren't rendered.
115, 3948-3949: -> that may contain contents composed of one or more media types.
Note the use of "may" does not require more than one, but at least one. Yes?
115, 3919-3926 to express - reform
112, 3820-3822 This seems confused to me.
"A version is a version control metadata that contains a version number, label, and description."
"A version" here refers to something subject to versioning, for which we have version metadata.
Perhaps -> A version is a object for which versioning metadata containing version number, label and description is recorded (captured, whatever).
A version object is a version control metadata of a versioned copy or a private working copy of a versionable artifact.
Perhaps -> A verion object contains the version control metadata for a versioned object. ???
112, 3800 "A checked out comment of a version series."
I think we meant: A comment on checkout of a version series. Yes?
110, 3734-373 is a version control -> is version control
109, 3693-3694 - characteristics of entities? ...for version control?
109, 3676-3676 - entities? Don't know where that comes from, unlike folder, artifact, etc.
109, 4.3.2.1 Description - usually description, only now lapses into MUST language. Need to separate into a subsection at least.
---------------------------------------------------------------------
To unsubscribe, e-mail: icom-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: icom-help@lists.oasis-open.org
-- 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) OASIS Technical Advisory Board (TAB) - member Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]