[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Do we need link-catalogs for schemas?

  • From: "Bill la Forge" <b.laforge@j...>
  • To: "Murray Maloney" <murray@m...>, <xml-dev@i...>
  • Date: Fri, 9 Oct 1998 13:19:03 -0400

Re: Do we need link-catalogs for schemas?
Two concerns here:

        1. There should be a way to cascade whole Bind documents,
            not just individual entries, as well as adopting a
first-encountered
            entry rule. This would allow one Bind to override another,
            dropping inappropriate items under an entry.

        2. Binding an entry to a class should be accomplished without
            recourse to a link. This would allow for light-weight bindings.

From: Murray Maloney <murray@m...>

>I think that it is definitely worth looking at Rick's proposal.
>I can imagine how SOX could use and benefit from this kind
>of binding mechanism for every element, attribute, datatype,
>entity, notation, and even PIs and namespaces themselves.
>
>I would hope that such a binding mechanism would allow one
>to associate XML objects with various flavors of semantics:
>behaviour (IDL, Java, etc.), meaning (prose, images, etc.),
>style sheets (CSS, XSL, etc.), equivalences (UML, XSchema, etc.),
>and other relationships.
>
>Regards,
>
>Murray
>
>At 09:51 AM 10/9/98 -0400, Rick Jelliffe wrote:
>>
>>Perhaps it is time to (attempt to) ressuscitate XML-Bind. This was a
project of
>>mine which I put forward during the Namespaces debate. The thrust of this
was that
>>the then namespace draft conflated two things:
>>    * some way to *bind* GIs into public identififiers (URL+GI or
whatever) {this
>>is what the current namespace has limited itself to}
>>    * some way to *link* this identifier to all sorts of interesting
information.
>>I tried to push the idea that having just a simple "src" attribute in the
namespace
>>PI tied restricted it arbitrarily, and had the bad effect of hardwiring a
single
>>vendor's schema.
>>
>>So instead I pushed a catalog idea, and in particular that the namespace
proposal
>>actually reflected a need for a new kind of link: linking from element
types rather
>>than from instances on elements. One wants to name them because one wants
to link
>>to or from them. I would like to raise this link-catalog idea again.
>>
>>The link-catalog idea was that potentially every stakeholder (end-user,
document
>>creator, browser-maker, DTD/schema creator) may want to use these
type-links (for
>>documentation, schema distribution, etc).  It would be best if this were
explicitly
>>marked up using XLL extended links. A document should be able to have a
web of
>>type-related resources linked to/from it.
>>
>>Now the great thing about using instance syntax for new schemas (e.g.
XSchema) is
>>that
>>no new linking declaration system needs to be invented: we can define any
kind of
>>link we need and markup the element in the Xschema instance. That way we
get
>>type-links.
>>
>>So now we are at the stage:
>>
>>1) namespace proposal binds GI names to public identifiers
>>2) XSchmema proposal (and its ilk) can allow links from GIs to a catalog
(e.g.
>>using a fixed attribute) *but* we need to actually do it;
>>4) XLL proposal allows extended links, with which we can implement a
catalog
>>system, *but* we need to actually do it.
>>
>>So I would propose that XML-DEV should design an element set for catalog
entries,
>>it should cascade or be able to link with other catalogues. It might be a
valuable
>>enhancement to XSchema, and indicate to the W3C schema people the
direction that
>>people would like to go. (In particular, that there are many possible
schemas, and
>>even natrual language documents are valuable for defined document types.)
>>
>>The kind of thing I am thinking of is this:
>>
>><!-- example of a 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>
>>       <!-- 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" />
>>        <a href="www.ms.com/html4.txt#p"
>>            role="-//www.ms.com/NOTATION DCD//EN" />
>>        <a href="www.netscape.com/html4.htm+p"
>>            role="-//www.w3.org//NOTATION RDF Schema//EN" />
>>        <!-- links to documentation -->
>>        <a href="www.vhg.org/html4/p"
>>            role="-//XML-DEV//NOTATION Virtual Hyper Glossary//EN" />
>>        <a href="www.schema.net/documentation/EN/html-paragraphs.htm"
>>            role="-//XML-DEV//TEXT English Documentation//EN"/>
>>        <a href="www.schema.net/documentation/DE/html-paragraphs.htm
>>            role="-//XML-DEV//TEXT Deusche Erklaerung//DE"/>
>>        <!-- links to further catalogs -->
>>        <a
href="www.schema.net/link-catalogs/html/p/link-catalog.xml#lc26"
>>            role="-//XML-DEV//SGML Link Catalog/EN"/>
>>    </entry>
>></XML:DEV:catalog>
>>
>>In this example there is a single entry. The description field indicates
the
>>catalog entry relates to HTML paragraphs.  The first lot of links link to
schema
>>definitions for HTML paragraphs, given in various notations (DTD, XSchema,
DCD, RDF
>>Schema). Then comes documentation for it in various ways (VHG, English,
German).
>>Finally comes a link to another link-catalog, which allows cascading or a
web of
>>links.
>>
>>In each entry, I have used an XLL href (a URL) and used an SGML FPI
(Formal Public
>>Identifier) for the role atribute.  Anyone who wants to define a new role
would
>>make up a new FPI for that role. XML-DEV would create a good starting set
of FPIs
>>for the catalog:
>>    DTD
>>    XSchema
>>    English Documentation  (.. and so on for every language)
>>    link-catalog
>>
>>After that, there should be some kind of new attibute in Xschema,
available on all
>>elements, called perhaps  "link-catalog-href". This contains a URL
pointing to an
>>XML-Dev link-catalog
>>
>>IMHO this kind of thing would be a major addition to the power of XML: the
W3C
>>efforts to define a new single schema definition language are, to some
extent,
>>misguided and out-of-sequence in that it would be better to first set up
an
>>infrastructure by which schemas and documentation can be located.  I am
not
>>convinced that having multitudes of schema definition languages is a bad
thing:
>>perhaps it is better to let companies compete and just provide an
infrastructure
>>which allows them to provide good product without hijacking documents.
>>
>>Cheers.
>>
>>Rick Jelliffe



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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.