- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 14 Apr 2009 18:37:14 +0000
- To: www-xml-schema-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6009
--- Comment #4 from John Arwe <johnarwe@us.ibm.com> 2009-04-14 18:37:13 ---
(In reply to comments #2 and #3)
> 2.2.1.1 Type Definition Hierarchy ... restriction overlaps extension
Looks great.
> 2.2.1.2 Simple Type Definition
> This appears to say mixed=yes => never a simple type def. Yes?
I must have been tired, given the backwards paraphrasing of the logic. I was
in fact equating "no element children" with "mixed=no", so thanks for the SGML
education in the email. The sense in which I meant it was your (c) "For some
complex type T, if T.{content type}.{variety} = mixed then T.{content
type}.{variety} != simple." and I was simply confirming that this was the
correct understanding of the text's intent, not requesting any change. Had my
understanding been incorrect, then I would have considered requesting a change.
> 2.2.2.1 Element Declaration
> "...by triggering identity-constraint definition ·validation·."
ok
> 2.2.2.2 Element Substitution Group
> Actually, this sentence is referring to XML DTDs
Yikes! New text does a much better job of naming the alligators in this moat.
> 2.2.2.2 Element Substitution Group
> New?
ok
> 2.2.4.2 Type Alternative
Maybe I'm now too close, but I had no reading problem with TA instead of TAC.
If the inconsistency is ok with the wg, I can certainly live with having
pointed it out once so it's clearly a conscious choice.
> 3.3.2.1 Common Mapping Rules for Element Declarations - XML Mapping
Summary clause 2
Much clearer, thank you.
> 3.3.1 The Element Declaration Schema Component
Much clearer to me. Since recursion is here to stay, any further editing seems
close to/past the point of diminishing returns.
> 3.3.4.3 Element Locally Valid (Element)
No, no, keep the original text. I was mis-reading it in a different way vs
your email; I was mentally inserting *...* "*the namespace of* D is not absent
and...", so it was precisely the information you cited that led me to think
that any D with a nsuri of [absent] would fail this clause (and hence NEVER be
locally valid).
> 3.3.5.1 Assessment Outcome (Element)
Net: no change required.
I think it was a simple case of (a) not remembering the existence of such a
property from 1.0, so I concluded it was new, and (b) not seeing anything in
1.1 at this point to introduce such a property, and (c) reading a paper copy
then later copying text into comments. (c) is important because it made the
hyperlink invisible. Any new reader would still fit into a&&b, potentially
into a&&b&&c, but the probability of c seems much lower past the initial
drafting phase (i.e. once it's a Rec, most people would use the on-line version
for reference and would therefore see the hyperlink).
> 3.3.5.2 Validation Failure (Element) error code types
So I think the closest pragmatic answer is that schema error codes are
(logically at least) of type xs:anyType or maybe (#PCDATA)*. Fair enough, to
the (apparently small) degree that such questions are "widely" considered fair.
Nothing to see here, move along.
Of course, I could (ok, will) also note that "Outcome Tabulations (normative)
(§C))" says "...this section tabulates and provides unique names for all the
constraints listed...". If it provides -names-, one hopes that said names are
in fact QNames vs local-names (since that is a pretty clear Best Practice), and
said appendix should clarify which namespace they are in (unless a more general
statement earlier is rule to cover this, along with (presumably) all other
names defined in this document).
> 3.3.5.2 Validation Failure (Element) more than one ... fails to be satisfied
- I notice in "[failed identity constraints]" you lost a verb ("that not
satisfied").
- Your email starts out by appearing to argue that [schema error code] (to
choose a concrete example) contains (in principle) all such codes that result
from a given schema validation episode, while the two [failed...] properties in
question are defined differently. The proposed Notes seem to very much echo
the [schema error code] proposition however (in principle complete, what a
given processor makes visible varies), so I'm not seeing any functional
difference. From what I'm understanding, there are two (seemingly low-pain)
approaches:
1. in the draft Notes, replace "property includes all" with "property includes
a subset of" (relying on the fact that every set is a subset of itself, so
"all" is still permissible).
2. Remove the two Notes entirely, and let section 2.1 paragraph 1 (processors
may not show you everything) govern all of these equally.
I'd tend to prefer (2) myself, but can certainly live with either.
> 3.3.5.4 Element Validated by Type
> Impossible ... actually: the choice ... was removed in 2006.
LOL - I have *really good* glasses.
Think you need a space, that aside looks fine.
from: specifying lighterweight interfaces
to : specifying lighter weight interfaces
> 3.4.2.3 Mapping Rules for Complex Types with Complex Content
ok
> 3.4.4.1 Context-determined Type and Context-determined Type Table
NEW Typo (; to .)
from: legitimate; The ·locally declared type·
to : legitimate. The ·locally declared type·
> 3.4.4.1 Context-determined Type and Context-determined Type Table
> loath to rephrase without mentioning functions
The rephrase is clearer to me. This seems like a case where the implementers'
need for precision simply outweighs the average readers' need for clarity, so
ok.
> 3.4.4.1 Context-determined Type and Context-determined Type Table
> " This mapping serves as a context-determined type ..."
fine.
> 3.7.2 XML Representation of Model Group Definition Schema Components
looks fine; FYI it did not get flagged as a change.
> 3.10.4.2 Wildcard allows Expanded Name
> Validation Rule: Wildcard allows Expanded Name - clause 4
I'm agnostic on the addition to 1.5. While I remember the implication truth
table from school, this is simply a usage of it I've not had to cope with since
Logic classes (in procedural programming, if the antecedent is false you stop
but one does not "consider" the truth value of an action, that is an ill-formed
question). There is nothing wrong with the spec though (that I can see).
> 3.13.4.1 Assertion Satisfied
> so they cannot be referred to.
I understand the mechanism. The additional note does clarify that Schema is
not requiring the XDM processor to treat such references as errors, which is
what I was unsure of. The latter part above still sticks in my craw just a bit
(technically the issue is not that one cannot "refer" to that content, but that
doing so will not return what is intended, which is no doubt how you got to
"unsuccessful" in the first place). I would be tempted to truncate the portion
above, but can live with it too.
> 4 Schemas and Namespaces: Access and Composition
ok, ok, call off the African honeybees I'll stop poking the nest.
> 4.1 Layer 1: Summary of the Schema-validity Assessment Core - bullet 2
ok so this is just a matter of declarative vs procedural. The spec is
intending to be declarative on this matter, and I was thinking procedurally
when I posed the question. Fair enough.
> 4.2.4 <override>
ok (o, to have a Monty Python quote addressing this, but until then: Nee!)
> 4.2.5.1 Licensing References to Components Across Namespaces
> xhtml ns
Always happy to prove I can play the naive reader with the best of them.
Since the example below the notes DOES in fact import the html ns, it would
seem clearer to be fully pedantic in the example's documentation content
from: We do NOT need to import the xhtml namespace into the schema, we only
need to declare the namespace prefix.
to : This use requires us to define the xhtml namespace prefix, but it does
NOT require us to import the xhtml namespace into the schema.
from: <xs:element ref="xhtml:p" minOccurs="0"/>
to : <xs:element ref="xhtml:p" minOccurs="0"/>
<!-- The reference to xhtml:p above requires us to import the xhtml
namespace into the schema -->
(or similar)
> 4.2.5.1 Licensing References to Components Across Namespaces
> "...prefixes declared with namespace declarations in the normal way..."
I think I was (obtusely) questioning whether a choice of 1.0 Datatypes
(implying XML 1.0 and XML Ns 1.0) in a given schema assessment episode
(licensed by 1.4) could possibly conflict with the Structures dependency on
Namespaces 1.1 (no license to use Ns 1.0 given in section 1.4 of this spec).
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 14 April 2009 18:37:24 UTC