xml-dev - Re: External Resources: Catalogs, XInclude, XBase

[Paul Grosso <pgrosso@arbortext.com>]

At 13:47 2000 04 17 +0100, Leigh Dodds wrote:
>I've got a question relating to Catalogs, XInclude and XBase
>(and Packaging I guess)...
>
>Catalogs provide a means to declare a local resource (external entity, 
>DTD) as the target of a public identifier. This facilitates 
>offline processing, and may improve performance in some apps 
>(intranet/filesystem vs internet retrieval).

Yes.  In general, entity management catalogs (which is what we're
talking about here) are things that map given information about 
external entity declarations into something (a "storage object
identifier" which, in Web-talk might be called a resource 
identifier or just a "URI reference") that addresses the resource
that is to be used as the external entity itself.  This mapping
facilitates lots of use cases.

>XInclude [1] provides a means to include external resources (xml, cdata, 
>text) using a URI. The WD declares the XInclude to be complimentary 
>to external entities [2] but later says [3] that 
>
>"It may be possible to replace many instances of entities 
>with the inclusion mechanism"

All it's saying is that external entities can be used in conjunction
with xinclude (after all, external entities are part of XML 1.0, and
that's a fact that can't change), but many of the use cases for
which people are currently using the external entity construct could
be addressed using xinclude.

>Yet XInclude doesn't support any notion of PIs or Catalogs, or 
>in fact anyway to redirect inclusions to locally held resources.
>
>Isn't this something of a problem? Doesn't the usefulness of 
>a PI/Catalog mechanism also apply in this case?

I'm not sure what PIs have to do with this discussion.  Catalog
use is orthogonal to XInclude use, so XInclude neither supports
nor prohibits catalog use any more than XML 1.0 itself does.

It would be perfectly reasonable for a processor that supports
catalog use to treat the URI given on an xinclude as it would
any external identifier and pass it through the catalog processing.

Perhaps the XInclude spec could make it clearer that the value
of its href attribute is similar to a system identifier in the 
sense of that associated with the SystemLiteral of production [73]
in the XML spec so that catalog processing (if any) would occur on 
it too.

>Also, wouldn't a Packaging mechanism require similar functionality?

I'm not sure what similar functionality you mean.  A packaging
mechanism (i.e., some way to be able to refer to--and perhaps
facilitate transmission of--a related set of files) would sure
be nice.  It's on the "future" list of the XML Activity, but at 
the present, there aren't enough cycles to attack the problem.  

There are some similarities between an entity management catalog
and a "manifest" that might be used as part of a packaging
mechanism (in fact, the OASIS [nee SGML Open] TR9401 Entity
Management Catalog Resolution [4] confused the two a bit
[mostly my fault!], and included the section on Issue B in
an attempt to address packaging somewhat), but it would be
better to approach packaging from a more general viewpoint
and perhaps treat a catalog as just one other possible file
to include in the package.

paul

>[1]. http://www.w3.org/TR/xinclude
>[2]. http://www.w3.org/TR/xinclude#AEN1_5_2_1_4
>[3]. http://www.w3.org/TR/xinclude#AEN1_5_2_2

[4] http://www.oasis-open.org/html/a401.htm

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************