Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
Without a schema, you are simply expected to know that the
map
attribute is of type
xs:ENTITY
, and expected to pick up the attribute value in a call such as
unparsed-entity-uri(@map)
. This call returns the absolute URI of the actual resource, that is, something like
file:///c:/documents/forecasts/weather.jpeg
.
Unparsed entities are one of the more rarely used features of XML; they derive from SGML, and this explains why people who use unparsed entities are also inclined to use public identifiers to refer to them. Public identifiers were designed to tackle the same problem as URNs, namely to provide a way of giving unique names to objects, without becoming locked in to the location where the object can be found. They are often used in conjunction with Oasis catalogs.
Note that it is the public and system identifier of the unparsed entity that is returned, not the public and system identifier of the notation named in its
NDATA
clause. XSLT provides no way of finding out the notation name (
JPEG
in our example) or the URI for the notation, so even if you have a schema that flags the attribute as one that contains an unparsed entity reference, you still have to know what kind of reference you are expecting.
This is not exactly in the spirit of section 4.4.6 of the XML specification, which states: “When the name of an unparsed entity appears as a token in an attribute of declared type ENTITY or ENTITIES, a validating processor must inform the application of the system and public (if any) identifiers for both the entity and its associated notation.” However, unparsed entities are hardly XML's most widely used feature, so it is unsurprising that XSLT support for them should be incomplete.
The rules in the XSLT specification don't explicitly state this, but in practice, if you use a nonvalidating XML parser to process the source document, the parser isn't obliged to pass information to the XSLT processor about unparsed entities declared in the external subset of the DTD, and the
unparsed-entity-public-id()
and
unparsed-entity-uri()
functions are therefore likely to return a zero-length string. If this happens, try using a validating XML parser—assuming of course that the source document is valid.
Examples
If the DTD contains the declaration:
PUBLIC “-//MEGACORP//WEATHER/” NDATA JPEG>
then the expression
unparsed-entity-public-id(‘weather-map’)
returns the public identifier
-//MEGACORP//WEATHER/
.
Given the entity definition:
and the entity reference:
the following code will insert an
element into the HTML output:
See Also
Trees, Not Documents
, in Chapter 2, page 42.
unparsed-text, unparsed-text-available
These two functions are available in XSLT only
.
The
unparsed-text()
function returns the content of an external file in the form of a string. Its companion function,
unparsed-text-available()
, tests whether a call on
unparsed-text()
would succeed.
Signatures
The unparsed-text() function
Argument | Type | Meaning |
href | xs:string? | The URI of the external text file to be loaded. If an empty sequence is supplied, the result is an empty sequence. |
encoding (optional) | xs:string | The character encoding of the text in the file. |
Result | xs:string? | The textual content of the file . |
The unparsed-text-available() function
Argument | Type | Meaning |
href | xs:string? | The URI of the external text file to be loaded. If an empty sequence is supplied, the result is false. |
encoding (optional) | xs:string? | The character encoding of the text in the file. If an empty sequence is supplied, the function behaves as if the argument were omitted. |
Result | xs:boolean | True if a call on unparsed-text() with the same arguments would succeed; false if it would fail . |