OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   [Fwd: Defining "public interfaces" in specifications]

[ Lists Home | Date Index | Thread Index ]

FYI, since this is extending an idea first posted here :-)

Eric

-- 
Curious about Relax NG? My book in progress is waiting your review!
                                   http://books.xmlschemata.org/relaxng/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--- Begin Message ---
  • To: www-qa@w3.org
  • Subject: Defining "public interfaces" in specifications
  • From: Eric van der Vlist <vdv@dyomedea.com>
  • Date: 26 Oct 2002 10:23:42 +0200
Hi,

Not really sure this belongs to this list, but after the recent issues
with XML 1.1, I came to think that it would be a good thing to define
"public interfaces" in specifications.

These public interfaces would be, like in Java, definitions that a WG
(and the W3C in general) would commit to maintain or explicitely
depracate in future versions of the specs.

The definition of a XML Name could be an example of such interface.

If that had been the case, other specs such as XPath 1.0 could have
refered to "the latest definition of a XML Name" instead of nominatively
quote "the current definition of a XML Name in XML 1.0".

This has already been done with external specs and, for instance, XSLT
1.0 relies on the fragment definition for the mime type of the
dereferenced document in the definition of the document() function. In
other words, XSLT 1.0 relies on whatever will the definition of a XML
fragment be.

I think we could use this example to go still further than what I have
just proposed and define a global repository of "documentation
interfaces" without specifying in which specs these interfaces are
defined.

In the example of XML Names, a spec could then make reference to "the
latest definition of a XML Name" without specifying in which spec this
is defined and the repository would know where to find this definition.

This would allow to move definitions from a spec to another and may be
very usefull. For instance, consider XLink. Because this spec has been
the first to get the problem, XLink has defined the normalization to
apply to the representation URL found in an attribute to convert it into
a "real" URL. This definition probably doesn't belong here, but many
other specs (W3C XML Schema and even Relax NG for instance) made
references to this spec.

Making a reference to "the URL normalization rules" without mentioning
that it belongs to XLink would make specs much more modular.

And of course, a strict management of these "W3C definitions" would not
only help make specs more modular, reduce the need for "cascading
updates" but also increase their level of quality.

Hopes this might help.

Eric
-- 
Freelance consulting and training.
                                            http://dyomedea.com/english/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--- End Message ---




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS