[XSL-LIST Mailing List Archive Home]
[Reply To This Message]
Re: How to View Entity Reference
Subject: Re: How to View Entity Reference|
From: "andrew welch" <andrew.j.welch@xxxxxxxxx>
Date: Thu, 14 Sep 2006 15:19:52 +0100
On 9/14/06, David Carlisle <davidc@xxxxxxxxx> wrote:
> 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
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
Not that I'm a grumpy old sgml geek or anything, you realise...
Thanks for the explanation, although I think you need to be an SGML
geek to parse it at the first attempt.
The thing that surprised me is usually information in the DTD is lost
after the XML has been parsed - its not contained in the infoset. It
seems these are...
Is unparsed-entity-uri() the only function reliant on a DTD being used
in the XML?
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format