- From: <bugzilla@farnsworth.w3.org>
- Date: Fri, 09 May 2008 20:48:46 +0000
- To: www-xml-schema-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5151 cmsmcq@w3.org changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|needsDrafting |needsPublication ------- Comment #5 from cmsmcq@w3.org 2008-05-09 20:48 ------- 3 Properties in the PSVI Your argument seems "strange" given the context. Expanding the excerpt ever so slightly, in 3.1.1 we find: "Any property not defined as optional is always present; optional properties which are not present are taken to have ·absent· as their value. Any property identified as a having a set, subset or list value may have an empty value unless this is explicitly ruled out: this is not the same as ·absent·. Any property value identified as a superset or subset of some set may be equal to that set," Thus, in the already existing text, sentence 1 shies away from RFC 2119 vocabulary while both of the next two sentences, I think describing the same PSVI, use RFC 2119-style MAYs. This seems inconsistent. Yes, you're right; it is. I think the error is the use of conformance language in the sentences containing "may". But at the moment I do not have a good reformulation for them. 4 "One of the following" ... 3 eyebrow hairs of concern arise at "fairly obvious that the items are mutually exclusive", since "fairly obvious" is Eye of the Beholder territory. ... Point well taken. My lowest-cost fix would be to state in 1.5 that in cases where the authors believe the list items to be mutually exclusive, [this language] has been used. While the authors are most likely right when assessing whether a set of options falls into the ==1, >=1, 0 or 1 sorts of categories, that is still their assessment (dare I say assertion) and hence it may be wrong, however unlikely. Sometimes I worry that 1.5 is getting kind of crowded, but I think this works for me. 5 MUST vs "is" or "apply" ... We simply read the suggested words to mean different things. I mentally append "in order for the constraint to be met" after each of these, which is for most humans functionally equivalent to "in order for the 'thing' to be valid". So, for me, they are still contingent. If we want to reduce this down to modal logic, I think by definition you've just lost the majority of humans (regardless of how correct doing so might be). I should make clear that I don't believe either that the 1.0 spec intended the rules to be read in the light of modal logic or that 1.1 should do so. But I found it impossible to read the nested uses of MUST without stopping to say "well, this clearly doesn't mean what it says; as a reader I will have to make allowances for that." We don't have a lot of other reports, so maybe I'm the only reader who found it confusing. Since the WG made the change, however, either I persuaded them that it was an improvement or they were just humoring me and must now see the price to be paid for it. Taking the first citation as a concrete example: Schema Representation Constraint: Attribute Declaration Representation OK In addition to the conditions imposed on <attribute> element information items by the schema for schema documents, all of the following also apply: Cinching down the language lawyer hat, I have to ask what "apply" even means. Allowing for a bit more cranial circulation, I think the intent is one (or both, to me they are essentially the same) of the following: (1) In addition to the conditions imposed on <attribute> element information items by the schema for schema documents, all of the following conditions also are imposed: (2) In addition to the conditions imposed on <attribute> element information items by the schema for schema documents, all of the following conditions also must be tested: Either of those would, to me, be an improvement. I will not lay down in the tracks over it however. I like both of these. 7 The appropriate case "In this case, it's clear on examination that only one of the items can be true at a time." Kind of you to prove my point for me. In certain languages with "case", an otherwise is ALWAYS executed unless the individual when/if tests contain a "break". It is exactly this potential difference in assumptions I was pointing out. I'm not certain that I understand the issue you are raising here. I thought at first that it was "What happens if in a series of "if <condition> then <result>" items, more than one condition is satisfied?", which makes a difference in just those lists where the conditions are not mutually exclusive. (Hence the reply, which suggests that the list in question is not really ambiguous.) But now you're focusing on the "otherwise", which makes me think I didn't understand the issue here in the first place. Would rephrasing the boilerplate help? And if so, then rephrasing it how? Or if really the only thing for it is to say explicitly in section 1.5 what this idiom means, then (I'm sorry to be so dense) what exactly do you believe we should say about it, to make it clearer to readers?
Received on Friday, 9 May 2008 20:49:19 UTC