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 15547 - [FO30] analyze-string and schemas
Summary: [FO30] analyze-string and schemas
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Member-only Editors Drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-13 16:38 UTC by Tim Mills
Modified: 2012-10-02 12:56 UTC (History)
1 user (show)

See Also:


Attachments

Description Tim Mills 2012-01-13 16:38:18 UTC
According to F&O 3.0:

"A schema is defined for the structure of the returned element, containing the definitions below. The returned element and its descendants will have type annotations obtained by validating the returned element against this schema, unless the function is used in an environment where type annotations are not supported (for example, a Basic XSLT Processor), in which case the elements will all be annotated as xs:untyped and the attributes as xs:untypedAtomic."

Does this therefore mean that these schema types and element/attribute declarations are in-scope?  That is, is it permissable to use

schema-element("http://www.w3.org/2005/xpath-functions":analyze-string-result)

without raising error XPST0008?
Comment 1 Michael Kay 2012-01-13 17:16:05 UTC
I don't think the current text says anything which would allow you to infer that these types are in-scope. The mere fact that an instance document carries a type annotation doesn't make the name of that type available at compile time.

We could choose to make these type names "built in" so that they are always in-scope, but we don't currently do so, I think.
Comment 2 Michael Kay 2012-03-20 18:30:44 UTC
The WG determined that these schema types are not automatically part of the static context, though implementations are free to add them to the static context if they wish. (In which case they must declare that they do so, since addition of extra things to the static context is implementation-defined). A non-normative note to this effect will be added to the fn:analyze-string specification.
Comment 3 Michael Kay 2012-10-01 19:54:59 UTC
Added this note belatedly, as agreed. Note that F+O can only really say that the contents of the static context are host-language defined; a host language could if it wished say that these schema components will always be present in the static context. So the note says:

<p diff="add" at="L">The declarations and definitions in the above schema are not automatically
            available in the static context of the <code>fn:analyze-string</code> function call (or of any other expression).
            The contents of the static context are host-language defined, and in some host languages are implementation-defined.</p>
Comment 4 Tim Mills 2012-10-02 12:56:52 UTC
Thanks.