Re: [xsl] How to View Entity Reference

Subject: Re: [xsl] How to View Entity Reference
From: David Carlisle <davidc@xxxxxxxxx>
Date: Thu, 14 Sep 2006 14:24:44 +0100
> Yes, reading around briefly it seems that's how it works, although it
> looks like a really bad idea. Surely a legacy thing? (or is it widely
> used and I'm just blinkered?)

TEI (who invented much of what's now standard linking practice,
xpath-like path navigation, etc:-) use it a lot, not sure where else
it's used these days.

It's not such a bad idea really, if you go <img href="foo.jpg"/> you are
supposed to just know by some out of band knowledge that the incoming
data is a jpeg file (assuming your smart content negotiating web server
doesn't decide to send you an svg instead:-)

But NDATA entities are designed to allow you to formally declare
entities to be associated with specific types of things

> ".\Equations\008x0001.jpg" NDATA jpg>]>

so you know that file is of type jpg and if you wish you can define
<!NOTATION jpg PUBLIC "-/some formal identifier for the JPRG Standard">

So given some standard set of FPIs for image types (or link types or
anything else) a document can unambiguously decalre what stuff it
depends on (of course if you wish you can identify things in NOATION
using a SYSTEM identifier and a URI (eg a namespace name) rather than
an FPI)
Of course if you _have_ got a world wide web and content negotation and
stuff, while formally declaring  types of files is nice if it's
right, it's not nice at all if the types are wrong because you never
really know what type you will get until you ask. Also if it turns out
that in fact your browser can handle <img src="foo.anything"/> for all
sorts of file types using 3rd party graphics filters and plugins and
stuff, perhaps the early xml transformation stages really don't need to
know anything about the file types involved and just treat everything as
some opaque data that the end application will sort out, so NOTATION and
unparsed entities are decidedly less popular than they were, and their
cause wasn't helped when xsd schema botched the definition of NOTATION
(claimed that they were just included in schema for compatibility with
dtd, then made a definition which was incompatible with the dtd
definition)

Not that I'm a grumpy old sgml geek or anything, you realise...


David

Current Thread