(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