[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: EMBED and validation

• From: "Eve L. Maler" <elm@a...>
• To: xml-dev@i...
• Date: Tue, 02 Dec 1997 20:22:48 -0500

At 07:12 PM 12/2/97 -0500, Peter Murray-Rust wrote:
>At 10:29 02/12/97 -0500, Rob McDougall wrote:
>>Thanks to everyone for the replies.  I now (think I) understand how this
>>would be used.  This method does require that the person creating the
>>document specify all the URLs he will be "include"ing at the top of the
>>file.  This is somewhat inconvenient for someone who only inserts things
>>once into any given document.  If the documents are being generated on
>>the fly from some application, the application may have to perform two
>>passes to derive a list of filenames, or else "bulk up" the document
>>with lots of entities that may never be substituted.
>
>If you are going to 'include' binary 'files' (i.e. entities) then it gets
>more complex. This is my current analysis. It's probably wrong. (Are there
>any Java parsers which manage this?)
>
><!DOCTYPE CML [
><!NOTATION GIF
>	 PUBLIC "+//IDN ds.internic.net/rfc/rfc2046.txt//NOTATION 
>         Multipurpose Internet Mail Extensions::image/gif//EN">
><!-- I hope I have copied that right - please don't sue - typos are likely
-->
><!ENTITY mygif SYSTEM "my.gif" NDATA GIF>
><!-- an ENTITY declaration is required for EVERY image??? -->
><!ELEMENT CML (IMG)*>
><!ELEMENT IMG (EMPTY)>
><!ATTLIST IMG SRC NOTATION (GIF) #REQUIRED> <!-- I could include JPEG, etc-->
>]>
><CML>
><IMG SRC="mygif">
></CML>
>
>This is all required for one GIF. Every GIF requires an ENTITY. There
>*must* be an internal subset. There must be a registry for the FPIs, etc.

(One small note: XML does not currently require public IDs to be formal.
This doesn't materially change your point, though...)

>In XLL I can write a complete document:
><CML>
><IMG HREF="my.gif" XML-LINK="SIMPLE" SHOW="EMBED" ACTUATE="AUTO"
>MIME="image/gif"/>
></CML>
>(excuse the case insensitivity)

It's true that this is another way to do basically the same thing, a way
that relies on not only XML but also XLL.  In practice, a lot of SGML shops
don't use the "pure" way either; they just put a pathname in an attribute
value, and use proprietary means to indicate that the named file should be
output as a graphic or whatever.  XLL is definitely an improvement on that!

>>It would be nice if there was also an "inline" way of doing includes
>>that would allow the XML parser to validate the resulting content.

This feels a bit apples-to-oranges, because unless you're declaring XML
itself as a "foreign notation" through a NOTATION declaration, you don't
need a lot of the overhead you've shown above:

<!DOCTYPE CML [
<!ENTITY mycontent SYSTEM "mycontent.xml">
]>
...
&mycontent;
...
</CML>

>Well, XLL does this ***as long as we agree on the semantics***.  HREF (or
>IMG/SRC) is so widely used in HTML that people will certainly start doing
>their own thing. There are the following possibilities:
>	- wait for a W3C body to pronounce (won't be this year, I suspect)
>	- wait and see what commercial browsers do
>	- invent nine-and-sixty ways of doing it
>	- use XDEV: as at least a means of coordinating *some* people.
>	
>JUMBO will start with the latter, and junk it as soon as anything official
>comes along... 

XLL itself isn't intended to pull in content and have it validated as part
of the same context in which the linking element appears.  I think you'd
have to use the DOM to dynamically change your document, and then reparse
if you choose to.  E.g., if you were to define a ROLE attribute value that
means "parse me in context once you've pulled me in," you'd have to start
another XML processor pass to do this, and it would be part of your own
application semantics, not those of XLL.

>[BTW I am not very happy with the idea that FPIs are intended to be human-
>but not machine-readable. That makes them useless for things like image/gif.]
>
>	P.

	Eve

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Prev by Date: RE: EMBED and validation
• Next by Date: RE: EMBED and validation
• Previous by thread: Re: EMBED and validation
• Next by thread: Re: EMBED and validation
• Index(es):
  • Date
  • Thread