This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5141 - small editorial changes section 3.4-3.6
Summary: small editorial changes section 3.4-3.6
Status: RESOLVED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: PC Windows XP
: P4 minor
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard: editorial cluster
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2007-10-08 15:52 UTC by John Arwe
Modified: 2008-03-20 13:48 UTC (History)
0 users

See Also:


Attachments

Description John Arwe 2007-10-08 15:52:19 UTC
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"
Comment 1 John Arwe 2007-10-08 20:56:47 UTC
3.8.1 bullet 2 
from: "(choice) corresponded to exactly"
to:   "(choice) correspond   to exactly"
Comment 2 C. M. Sperberg-McQueen 2008-02-04 16:17:25 UTC
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'. 
Comment 3 C. M. Sperberg-McQueen 2008-03-08 01:02:10 UTC
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.
Comment 4 Sandy Gao 2008-03-17 20:49:38 UTC
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.
Comment 5 John Arwe 2008-03-19 18:50:06 UTC
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.
Comment 6 C. M. Sperberg-McQueen 2008-03-19 21:22:29 UTC
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.

Comment 7 John Arwe 2008-03-20 13:48:30 UTC
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.