[Bug 5157] 3.4.2 example unclear

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5157





------- Comment #3 from johnarwe@us.ibm.com  2008-02-15 17:21 -------
Thank you for clarifying the default binding point that I missed.  If anyType
is not a valid default binding, then clearly the two are different.  Since this
is a concrete example, it might be beneficial to point out _why_ the two are
different on the premise that if I missed it, others will, instead of relying
on the perserverance of each reader to derive your conclusion independently. 
While the full general case of possibilities might be a confusing mishmash, in
this concrete example I think you have a pair of concrete values in mind (just
state them, let the reader decide if they can/care enough to attempt to follow
the reason that led to those values).

I think I follow the majority of the rest of your comment; I am equally
confident that I am still missing some fine points.  Maybe I can better explain
my (possibly derailed) train of thought that led to the two questions that
sound so strange.

notQname="speaker".  If speaker is a Qname, since it is unqualified, its ns URI
in this example must be the default for the schema (fair, fine, no problem). I
then wonder about the scope of its local portion.  Mentally I think I treated
it like a local element declaration, which led to the "which symbol space is it
in" question, since ("clearly") when trying to assess an instance against the
schema and testing the notQname condition one needs to know the {ns URI, local
name portion, symbol space of local name portion} triple of both the lvalue and
the rvalue in order to properly test their equality.  

It is also possible I might mis-understand the relationship between the symbol
spaces of a base CTD and each of its restrictions; I assumed them to be
disjoint, and it was simply part of the "valid restriction" constraints that in
the case of duplicate specifications, like <monitor>, that the symbol space of
the local name portion was ignored (treated as equal) in the comparison.

It might be the semantic intent of notQname="speaker", taking it as the lvalue,
is that "speaker" is treated as being in the same symbol space as the rvalue
during each comparison in turn to see if the instance's <speaker> is allowed to
match the schema's xs:any notQname, I simply did not think of that.  If the
text was trying to tell me that, obviously I missed it (i.e. a larger more
impressive club is needed for my noggin).  I could see that being expressed by
saying that the symbols spaces are irrelevant during wildcard matching, or
always assumed to be equal (to me those are equivalent, but they may well not
be to those more versed in the schema arts).

When (1.0) it was just ns URI comparisons for the wildcard matching, this issue
did not exist of course.

So to wrap around to your response, the expanded names in the wildcard are
connected to symbol spaces for me precisely because the local portion of the
expanded name (i.e. the NCName), in the context of a schema element
declaration, exists in a symbol space.  Writing that out makes my thinking
evolve a bit... during assessment, the instance whose content is being matched
(attributed) to schema components has no symbol spaces.  In order to possibly
match a wildcard, the instance's governing type definition cannot have a
potential match(?), so "by definition" each notQname list component corresponds
to a "potential instance" - since they are not local element declarations, the
potential instances have no symbol spaces, and I could see from your side why
the question seems terribly ill-formed.

I'm willing to leave the rest of the technical issues you pointed out as
something the wg will address.  Since it is an example, I might be very tempted
to take the simpler and not fully precise route.  Your "if X, then ...,
otherwise ..." construct seems acceptable for that purpose, and certainly no
more complex than other Structures content.

Received on Friday, 15 February 2008 17:21:51 UTC