Altova Mailing List Archives


Re: docref example/explanation?

From: "G. Ken Holman" <gkholman@-------------------->
To:
Date: 5/3/1999 5:55:00 PM
At 99/05/03 18:19 -0700, Mark D. Anderson wrote:
>so doc() and docref() do essentially the same
>thing, except that doc takes a scalar argument, and docref
>takes a vector (node-set) argument?

Yup ... that's what I read!  And the engine obtains URIs from the members
of the node-set.

>are there any dictums about what sort of URI a compliant processor
>must know how to handle? for example, at least "http:" and "file:"?
>how about a pipe?

I don't see any in the documentation.  I'll let James comment on that.
Could that just be vendor-specific differentiation?

>how does the processor signal that:
>- it doesn't know how to handle the uri's scheme
>- it gets an access denied error accessing the resource
>- the resource does not exist
>- the resource is not well-formed
>- the resource has nothing in it

My guess for all the above is that the node list returned is empty (which
can be tested for in the stylesheet) and I would hope the XSLT processor
I'm using would give me some error log I could review if my stylesheet code
reported that nothing was found.

>what dtd is the resource validated against?

For XML files, the resource needn't have a DTD and I would suppose the
answer would be the same as for any resource used as the source file to the
process.

>suppose i have a source xml document with an xlink:
><employee>
><employer xml:link="simple" href="http://some.company.com/employer.xml"
show="embed" actuate="auto">
></employee>
>and stylesheet fragment like this:
><xsl:apply-templates select="employee/*"/>
>would a compliant XSLT processor have to deal with the above the same as if
>it were given this source:
><employee employer="http://some.company.com/employer.xml"/>
>and had this stylesheet fragment:
><xsl:apply-templates select="doc(@employer)"/>
>?

I'm waiting to better understand XLink before trying to grok the nuances of
that question.

>does the processor timeout if it can't get the resource in time?

Processor-specific behaviour?  Vendor differentiation?

>is that a system-property? 

Perhaps with a private namespace, but I suspect not with the XSLT namespace.

>is a compliant processor prohibited from loading resources 
>from doc/ref expressions that aren't activated, and must any
>other resource exactly once?

I don't see a section on compliance.

>can it load the ones it will load in parallel and in any order?

I think that is immaterial as the stylesheet just obtains root nodes of the
documents.

>if i understand this correctly, for the sanity of xslt programmers
>it is actually now necessary for XPointer and XSLT to converge, since
>doc/ref would naturally use xpointer syntax in uri, while the
>rest of a style sheet uses xslt expressions?

Certainly it would use that syntax (the fragment identifier) if it only
wished to obtain some subset of the resource and point to the start of that
resource as a root.

Not having implemented an XSLT engine, and only having written stylesheets,
I'm not the best one to answer your implementation specific questions, but
I hope what I've offered above is helpful.

................... Ken


--
G. Ken Holman                  mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.           http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0  +1(613)489-0999  (Fax:-0995)
Website: XSL/XML/DSSSL/SGML services outline,  XSL/DSSSL shareware,
         stylesheet resource library, conference training schedule,
         commercial stylesheet training materials, on-line XSL CBT.
Next instructor-led XSLT Training:                  WWW8:1999-05-11


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.