Lists Home |
Date Index |
- From: Peter Murray-Rust <email@example.com>
- To: firstname.lastname@example.org
- Date: Fri, 26 Jun 1998 08:32:49
Peter Murray-Rust <email@example.com> writes:
> At 15:36 25/06/98 -0400, John Cowan wrote:
> >Perhaps there should be a convention mapping MIME types onto XML
> >notation names. Of course, the "/" in MIME types isn't an XML
> >name character, so it would have to be mapped into something else.
I'd imagine whatever syntax we chose, the actual MIME reference would
be inside of a literal, so I don't think the slash character is an issue.
Notations could be identified by MIME type, but that would limit the
available notations to existing MIME types, and that certainly would be
> Without really knowing anything about NOTATION this seems a good idea.
> Whenever I ask "why can't we have MIME support in XML?" (e.g. for an HREF
> target) I am told by the gurus that NOTATION should be used. If there is an
> algorithmic mapping, then I can use MIME and it can be converted into
I agree in part. NOTATION declarations are used to assign a unique name to
the notation, language or format of an external entity. GIF, Java, ActiveX,
ECMAScript, etc. all come to mind as descriptors of something that might be
typical notations used in XML documents. As an example, our Sun version of
DocBook (SolBook) declares twenty-six notations. Any time an non-SGML
external entity is declared in a SolBook document, the declaration includes
a reference to a previously-declared notation, such as
<!NOTATION GIF89a PUBLIC
"-//CompuServe//NOTATION Graphics Interchange Format 89a//EN">
<!ENTITY fig3 SYSTEM "figure3.gif" NDATA GIF89a >
Declaring and referencing an entity with a GIF89a notation then infers that
a processor is available which understands the GIF89a notation. Linking this
processor with the document requires some link between the notation name,
the processor and the entity. In Arbortext's AdeptEditor, in HTML browsers,
etc. this is all hardwired. We can't rely on hardwired notations like we
did in HTML.
What we need is not only a way to label the notation of an external
entity (which we have), but also a standard syntax that can associate an
external processor and/or any other necessary processing infrastructure
inferred by the notation. This is metadata, not part of the document content
If we attempted to architect this with common SGML principles, we'd try to
separate this processing-specific information (both the processor and
any processing instructions, ie., scripts) from the document content in
order to keep the content portable and not bound by specific processing
requirements. Or at very least, authors should have that option.
A 'Simple' Scenario
1. declare a notation
2. upon referencing an entity with that non-XML notation, link
the notation of the entity with the declared notation to
retrieve the URI of the processor.
3. check your cache of processors. If you don't have a
processor for this notation, retrieve one via the notation URI.
4. load the processor and feed it the entity URI.
5. sit back and enjoy the fireworks
The processor could be on the plug-in model. Anytime your application
came upon an unknown notation, it would download the plug-in to handle
that notation. There's a bit of a hitch though, as the XML spec does
not require that the notation declaration actually reference a processor;
it may simply reference a description of the notation. The purpose of
the notation declaration isn't really to link a processor but simply
declare the notation. We'd need to either modify this by making clearer
the processing expectations inferred by a notation declaration, or come
up with new syntax that performed this task. I'd suggest the latter.
We need a combination of Xlink (to perform the physical link) and RDF
(which provides the basic associative model). Notation declarations on
their own can't be relied upon as currently specified, and we certainly
can't require or even allow application-hardwired notations to become
the norm unless we're willing to settle back into the HTML browser world.
Murray Altheim, SGML Grease Monkey <mailto:firstname.lastname@example.org>
Member of Technical Staff, Tools Development & Support
Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900
"Give a monkey the tools and he'll build a typewriter."
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)