Do we need link-catalogs for schemas? (was Re: More namespaces perversion)
Rick Jelliffe
ricko at allette.com.au
Sun Oct 11 18:00:26 BST 1998
Charles Frankston ¼g¹D¡G
> Is there one "link-catalog" per document, or can I nest and scope
them?
> I.e. how do you deal with the fragment composition issue?
At its simplest, the link-catalog is just aweb of XLL extended pointers,
with
roles given using some nice FPI/URN mechanism. I dont see that it
should matter
if all the links were put in the same entry in the same resource:
<XML-DEV:link-catalog>
<entry id="lc1" GI="p" namespace="urn:www.w3.org/html4#p" >
<description>Links for HTMLs P element type</description>
<!-- links to schemas -->
<a href="www.w3.org/html4.dtd#p"
role="-//www.w3.org//NOTATION XML DTD//EN" />
<a href="www.schema.net/Xschema/html4.xml#p"
role="-//www.w3.org//NOTATION XSchema//EN" />
</entry></XML-DEV:link-catalog>
or inn different entries in the same resource
<XML-DEV:link-catalog>
<entry id="lc1" GI="p" namespace="urn:www.w3.org/html4#p" >
<description>Links for HTMLs P element type</description>
<!-- links to schemas -->
<a href="www.w3.org/html4.dtd#p"
role="-//www.w3.org//NOTATION XML DTD//EN" />
</entry>
<entry id="lc2" GI="p" namespace="urn:www.w3.org/html4#p" >
<description>Links for HTMLs P element type</description>
<a href="www.schema.net/Xschema/html4.xml#p"
role="-//www.w3.org//NOTATION XSchema//EN" />
</entry></XML-DEV:link-catalog>
or even in different resources
<XML-DEV:link-catalog>
<entry id="lc1" GI="p" namespace="urn:www.w3.org/html4#p" >
<description>Links for HTMLs P element type</description>
<!-- links to schemas -->
<a href="www.w3.org/html4.dtd#p"
role="-//www.w3.org//NOTATION XML DTD//EN" />
</entry></XML-DEV:link-catalog>
<XML-DEV:link-catalog>
<entry id="lc1" GI="p" namespace="urn:www.w3.org/html4#p" >
<description>Links for HTMLs P element type</description>
<a href="www.schema.net/Xschema/html4.xml#p"
role="-//www.w3.org//NOTATION XSchema//EN" />
</entry></XML-DEV:link-catalog>
I leave out other examples where one link in an entry merely points to
another
link in another entry, or points to another link-catalog in another
resource.
The link-catalog does nto need to be part of a document: it can be part
of an
application--an XML editor from Microsoft would presumably infer a
link-catalog
linking to Microsoft schema data (using Microsoft schema notations) in
augmentation to whatever link-catalogs were present in the particular
document
instance (or #FIXED linked from its DTD).
For nesting and scoping, a link-catalog link for the doctype element
(i.e. the
root) is enough to locate a whole schema. Minimally, all that is needed
is an
entry for every unique namespace. But individual entries can be used to
annotate
and extend schemas for particular purposes, in particular by adding
sub-schemas
and documentation. This is how people would expect such a link-catalog
to work.
Delegation is fine to provide, if users expect it.
The use of such a mechanism allows registration of various subclassing
mechanisms
too so that local poicy can be implemented:
<XML-DEV:link-catalog>
<entry id="lc1" GI="p" namespace="urn:www.w3.org/html4#p" >
<description>Links for HTMLs P element type</description>
<a href="html4/p/id-check.jar/"
role="-//Rick Jelliffe//NONSGML Java program to check a DOM
that
paragraph IDs start with small letter p//EN" />
</entry></XML-DEV:link-catalog>
In that case, the link invokes a validation program. My kindly browser
manufacturer might even define callbacks into which I can put data entry
programs:
<XML-DEV:link-catalog>
<entry id="lc1" GI="table" namespace="urn:www.w3.org/html4#p" >
<description>Links for HTMLs P element type</description>
<a href="html4/table-entry.jar/"
role="-//IDN ms.com//NONSGML IE6 Data Entry Program//EN" />
</entry></XML-DEV:link-catalog>
I
As far as nesting and scoping, I would tend not to want to provide any
mechanism.
The idea is to create a web of type-links which augment each other
rather than
replace. But I cannot see why any vendors could not implement their own
policy:
to ignore (but not delete) links using other vendor's schema or to
automatically
add or infer links to schemas at their own site. Or to prefer "close"
entries in
preference to "far" entries. I want to allow Microsoft to come up with
their own
schema system and to compete on that, but not exclude another vendor
from also
having their own system.
For new readers, the "composing of fragments issue" is this: if we cut
out a WF
fragment of one document and paste it into another, how can we cart
along all the
other information (catalogs, schema data, type links, etc). The
important thing
is that the link catalog entries are organized to GIs (other things may
be
possible, but I want to get GIs right first): these entries can be cut
up into
fragments just as simply as a document can be.
In a link-catalog system, the schemas themselves (or CSS, or whatever)
are not
cut up with the document. The same code which corrects the namespace
declarations during such cut and pasting also has enough information to
correct
link-catalogs. (Whether the link-catalog can stay the same (in which
case a
fragment carts around some of its orinigating context, which may be an
OK thing),
or just have the GI changed to the GI of the fragment, is not clear to
me. )
In a sense, there are already many kinds of data which are crying out
for this
kind of link:
MIME catalogs, CSS/XSL, Web schemas, all of these are based on linking
from type
information. (Actually, I suppose that with the namespace proposal,
even OASIS
SOCATs fall into class of inforamtion, to a certain extent. In the case
of MIME
catalogs, the grain is kept at the highest level, in the case of
CSS/XSL, the
grain is quite detailed structured information. We see on XML-DEV at the
moment
several discussions on how to create objects by linking methods to GIs.
The web would be richer, and many kinds of systems simpler, if there
were a nice
simple mechanism for doing this, such as this kind of link-catalog. As
I have
mentioned, I am not sure that there is a great need for a Web-Schema
system, such
as is being proposed. I think it would be much better fro W3C to agree
on simple
datatyping, and then agree on some link-catalog system with some
predetermined
FPIS so that basic standard schemas can be invoked (and also CSS, XSL,
DTDs, RDF,
SOCATs, MIME catalogs, etc). That leaves vendors free to develop
schemas which
are optimized for their constituency in whatever ad hoc consortia are
commercially appropriate.
In ISO I noticed a very strong feeling that when a standard moved to far
from
"infrastrucutre" to "application" it all got too political and
unsatisfactory,
and even perhaps anti-competitive and futile. One might think that a
schema
definition language is "infrastructure", but I rather fancy that it
might be
closer to "application", in that it undoubtedly will reflect the
capabilities of
the commercial products of its developers.
Rick Jelliffe
-------------- next part --------------
An embedded message was scrubbed...
From: Rick Jelliffe <ricko at allette.com.au>
Subject: Re: Do we need link-catalogs for schemas? (was Re: More namespace
s perversion)
Date: Sun, 11 Oct 1998 13:14:09 +0800
Size: 7676
Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981011/80db4700/attachment.eml
More information about the Xml-dev
mailing list