Do we need link-catalogs for schemas? (was Re: More namespaces perversion)

[Bill la Forge]

Real simple question: What is a GI?

Bill

-----Original Message-----
From: Rick Jelliffe <ricko at allette.com.au>
To: xml-dev at ic.ac.uk <xml-dev at ic.ac.uk>
Date: Sunday, October 11, 1998 12:01 PM
Subject: Do we need link-catalogs for schemas? (was Re: More namespaces p=
erversion)


>  Charles Frankston =BCg=B9D=A1G
>
>> 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=3D"lc1" GI=3D"p" namespace=3D"urn:www.w3.org/html4#p" >
>        <description>Links for HTMLs P element type</description>
>       <!-- links to schemas -->
>        <a href=3D"www.w3.org/html4.dtd#p"
>            role=3D"-//www.w3.org//NOTATION XML DTD//EN" />
>        <a href=3D"www.schema.net/Xschema/html4.xml#p"
>            role=3D"-//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=3D"lc1" GI=3D"p" namespace=3D"urn:www.w3.org/html4#p" >
>        <description>Links for HTMLs P element type</description>
>       <!-- links to schemas -->
>        <a href=3D"www.w3.org/html4.dtd#p"
>            role=3D"-//www.w3.org//NOTATION XML DTD//EN" />
> </entry>
> <entry id=3D"lc2" GI=3D"p" namespace=3D"urn:www.w3.org/html4#p" >
>        <description>Links for HTMLs P element type</description>
>        <a href=3D"www.schema.net/Xschema/html4.xml#p"
>            role=3D"-//www.w3.org//NOTATION XSchema//EN" />
> </entry></XML-DEV:link-catalog>
>
>or even in different resources
><XML-DEV:link-catalog>
>    <entry id=3D"lc1" GI=3D"p" namespace=3D"urn:www.w3.org/html4#p" >
>        <description>Links for HTMLs P element type</description>
>       <!-- links to schemas -->
>        <a href=3D"www.w3.org/html4.dtd#p"
>            role=3D"-//www.w3.org//NOTATION XML DTD//EN" />
> </entry></XML-DEV:link-catalog>
>
>
><XML-DEV:link-catalog>
>    <entry id=3D"lc1" GI=3D"p" namespace=3D"urn:www.w3.org/html4#p" >
>        <description>Links for HTMLs P element type</description>
>        <a href=3D"www.schema.net/Xschema/html4.xml#p"
>            role=3D"-//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=3D"lc1" GI=3D"p" namespace=3D"urn:www.w3.org/html4#p" >
>        <description>Links for HTMLs P element type</description>
>        <a href=3D"html4/p/id-check.jar/"
>            role=3D"-//Rick Jelliffe//NONSGML Java program to check a DO=
M
>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=3D"lc1" GI=3D"table" namespace=3D"urn:www.w3.org/html4#p" =
>
>        <description>Links for HTMLs P element type</description>
>        <a href=3D"html4/table-entry.jar/"
>            role=3D"-//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
>
>
>


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