Re: feature request

Subject: Re: feature request
From: "Don R. Day" <donday@xxxxxxx>
Date: Wed, 17 May 2000 01:05:15 -0500
Sebastian Rahtz writes:
> Rick Geimer writes:
>  > <!DOCTYPE foo [
>  > <!ELEMENT foo EMPTY >
>  > <!ATTLIST foo img ENTITY #IMPLIED >
>  > <!NOTATION gif PUBLIC "-//NATIONAL//NOTATION Compuserve gif format//EN"
>  > "" >
>  > <!ENTITY testimg SYSTEM "testimg.gif" NDATA gif >
>  > ]>
>  > <foo img="testimg"/>
> 
> something that I have never really understood is what good this
> NOTATION stuff really ever did. does anyone seriously use it? as
> opposed to second-guessing based on file contents?
> ...
> <foo img="testimg.gif" notation="gif"/>

Sebastian, your example provides the processing system with no
information about the characteristics of the non-XML data, should it
need to be transformed prior to use.

This method of referencing the artwork assumes 1) that the extension is
a true representation of the actual filetype and 2) that the content
type does not need to be transformed into a more appropriate format as
part of the publishing process (say, gif-to-eps for dropping into a
print job).

In a corporate SGML publishing system, the preferred notation may
actually declare a vector source format, and the required deliverable
form would be generated on-the-fly at production time.  In a situation
like this, having even more metadata about the particular ndata entity
would be particularly useful, but XML lacks these "data attributes" that
are appreciated in SGML systems.  What you can do with NDATA entities is
limited by this less expressive processing model.  And although you can
encode such metadata right at the point of reference, this causes the
information about an illustration to exist in more than one place,
increasing maintenance.  'Tis a oft-overlooked distinction between
"delivery form" and "source form!"

--
Don Day
<dond@xxxxxxxxxx>


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


Current Thread