W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2007

[Bug 4595] 1.0.3dev: document(*) with undefined context item

From: <bugzilla@wiggum.w3.org>
Date: Wed, 06 Jun 2007 19:23:20 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1Hw16G-0001Tq-Oa@wiggum.w3.org>

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





------- Comment #8 from jmdyck@ibiblio.org  2007-06-06 19:23 -------
(In reply to comment #6)
> 
> Just to clarify, do you suggest XPST0001 because you read C.1 Static Context
> Components as saying that the static type of the context item is not defined?

Yes.

> I don't know whether this is significant, but in the table in C.1, a
> monospaced font is used for the word "none" for the static type of the
> context item.  Other items marked as "none" use a sans-serif font.
> This lead me to believe that it was talking about the FS type "none".

Huh, I hadn't noticed that. (My browser's default fonts aren't distinct
enough.) 

(In reply to comment #7)
> 
> Yes, and the fact that someone added "(raises error on access)" also suggests
> that someone was thinking this way.

Actually, I think it suggests the opposite. That is, if the context item static
type is undefined, then it certainly raises an error (i.e., XPST0001) if you
try to access it. But if it's set to be the type that FS calls 'none', then it
*is* defined, so it doesn't raise an error when you try to access that
component per se, but rather when you attempt to use the type in static type
analysis.

So it would be clearer if it either said
    undefined (raises XPST0001 on access)
or else
    <code>none</code> (see FS 2.4.3)
respectively.
Received on Wednesday, 6 June 2007 19:23:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:33 UTC