5141 2007-10-08 15:52:19 +0000 small editorial changes section 3.4-3.6 2008-03-20 13:48:30 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only PC Windows XP RESOLVED FIXED editorial cluster resolved P4 minor --- 1 johnarwe cmsmcq www-xml-schema-comments oldest_to_newest 17060 0 johnarwe 2007-10-08 15:52:19 +0000 3.4.2 XML Representation of Complex Type Definitions, Complex Type Definition with complex content Schema Component, item 3.1.1 - looks like the property list should be indented further - lonely period before 3.1.2 3.4.2 XML Representation of Complex Type Definitions, ex 4 after tableau "A further illustration of the abbreviated form, " not clear to me what "further" is referring back to. looks unrelated to previous. 3.4.3 Constraints on XML Representations of Complex Type Definitions remove "only" from front of 2.1.2, 2.1.3 3.4.6, Schema Component Constraint: Type Derivation OK (Complex), note 2 "Note: The wording of clause 2.1 above appeals" unusual space after "Note:" makes reader unsure of scope of non-norm commentary 3.4.6, Schema Component Constraint: Type Derivation OK (Complex), note 2 from: "when the two types definitions in question" to: "when the two type definitions in question" 3.6.1 The Attribute Group Definition Schema Component from: "{attribute uses} is a set attribute uses, allowing for" to: "{attribute uses} is a set of attribute uses, allowing for" 17082 1 johnarwe 2007-10-08 20:56:47 +0000 3.8.1 bullet 2 from: "(choice) corresponded to exactly" to: "(choice) correspond to exactly" 18729 2 cmsmcq 2008-02-04 16:17:25 +0000 In an effort to make better use of Bugzilla, we are going to use the 'severity' field to classify issues by perceived difficulty. This bug is getting severity=minor to reflect the existing whiteboard note 'easy'. 19375 3 cmsmcq 2008-03-08 01:02:10 +0000 A wording proposal intended to resolve this issue was sent to the XML Schema WG on 7 March 2008. http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni-200803b.html (member-only link). It makes most, but not all, of the changes suggested; the status section lists the changes not made and gives some indication why not. Those interested in this issue are encouraged to review the proposal and to comment on it if they wish. 19512 4 sandygao 2008-03-17 20:49:38 +0000 At its telcon on 2008-03-14, the XML Schema WG adopted the wording proposal at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni-200803b.html (member-only link), and believes this issue now to be resolved. John, please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision. 19540 5 johnarwe 2008-03-19 18:50:06 +0000 I note that you skipped one change, in case that was unintentional, namely: 3.4.3 Constraints on XML Representations of Complex Type Definitions remove "only" from front of 2.1.2, 2.1.3 I can live with it either way; for me, removing the "only" makes it more readable. "if" alone would be clearer, "if and only if" alone would be clearer, the coder in me is less clear on which of those is intended by "only if...", however in this context it does not appear to matter. 19548 6 cmsmcq 2008-03-19 21:22:29 +0000 For the record: the retention of "only" in 3.4.3 is indeed intentional; as the notes in the wording proposal (in the Status section) say, "only if" is correct here. The editors (and I presume the WG) are taking "only if" as the converse of "if": p only if q == if p then q. The relation is not "if and only if", and not "if", but the former minus the latter. 19569 7 johnarwe 2008-03-20 13:48:30 +0000 If typos in the temporary status section matter, you'll want to change from: In 3.4.3 the suggestion to drop "only" has not been acdopted. to: In 3.4.3 the suggestion to drop "only" has not been adopted. wrt minding our p's and q's: que? former minus latter? http://www.math.hawaii.edu/~ramsey/Logic/Iff.html http://www.math.hawaii.edu/~ramsey/Logic/IfThen.html P Q If P, then Q (L) P if and only if Q (F') F'-L L-F' T T T T F F T F F F F F F T T F F T F F T T F F Using F'(ormer)=iff, L(atter)=ifthen from comment #6, when is F-L ever true? Or did I misinterpret your "minus" relation's meaning? I took it to mean: F'-L is true whenever F' is true and L is false. That's the abstract part of the problem. The concrete part can be shown by example: 3.4.3 Constraints on XML Representations of Complex Type Definitions Schema Representation Constraint: Complex Type Definition Representation OK In addition to the conditions imposed on <complexType> element information items by the schema for schema documents, all of the following also apply: 1 If the <complexContent> alternative is chosen, the type definition ·resolved· to by the ·actual value· of the base [attribute] must be a complex type definition whose {content type} does not have {variety} simple; 2 If the <simpleContent> alternative is chosen, all of the following must be true: 2.1 The type definition ·resolved· to by the ·actual value· of the base [attribute] is one of the following: 2.1.1 a complex type definition whose {content type} has {variety} simple; 2.1.2 only if the <restriction> alternative is also chosen, a complex type definition whose {content type} has {variety} mixed and {particle} a Particle which is ·emptiable·, as defined in Particle Emptiable (§3.9.6.3); 2.1.3 only if the <extension> alternative is also chosen, a simple type definition. 2.2 If clause 2.1.2 above is satisfied, then there is a <simpleType> among the [children] of <restriction>. 2.3 The ·actual value· of the mixed [attribute] is false. Using 2.1.3 (the shorter one), and comment #6, what exactly is the P in your p only if q formulation? I parse it as: only if P, Q that is, P="the <extension> alternative is also chosen" Q="a simple type definition" If I apply F'-L to this, it's never true (and then why is it in the spec). If I assume you swapped former and latter in comment 6, and got the minus relation correct, then L-F' is true when P is false and Q is true, i.e. 2.1.3 is true when "the <extension> alternative is NOT also chosen" AND "a simple type definition". That is a truly bizarre construction. fwiw, I think 2.1.3 is trying to say: if the CTD being evaluated is an extension, then (2.1) The type definition ·resolved· to by the ·actual value· of the base [attribute] is a simple type definition. That sounds an awful lot like an if-then to me.