[
Lists Home |
Date Index |
Thread Index
]
- From: Rick Jelliffe <ricko@allette.com.au>
- To: xml-dev@ic.ac.uk
- Date: Mon, 12 Oct 1998 00:07:27 +0800
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
- From: Rick Jelliffe <ricko@allette.com.au>
- To: Charles Frankston <cfranks@microsoft.com>
- Date: Sun, 11 Oct 1998 13:14:09 +0800
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
|
