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

Re: XIN: XML implicit namespace definitions

• From: Philippe Poulard <philippe.poulard@s...>
• To: Liam Quin <liam@w...>
• Date: Tue, 24 Mar 2009 19:17:59 +0100

Hi,

Liam Quin a écrit :
>   <try xin="try.xin">
>     <svg:picture>pretty!</svg:picture>
>   </try>

Wouldn't it be better if it was part of the XML family (the only one 
that is predefined and that doesn't require an xmlns declaration) ?
<try xml:xin="try.xin">

> 
> A workaround here is to use a different character:
> 
>   <try xin="try.xin">
>     <svg.picture>pretty!</svg.picture>
>   </try>
> 
> I don't like that very much but it would work.
> 
> It's also possible a XIN file could point to other resources,
> such as various sorts of schema for various purposes, XSLT or
> XQuery fragments for making RDF (RDFa/GRDDL) and so forth.

Yet another meta-catalog !!! I tried myself to design an extension of 
XML catalogs (OASIS) called Active Catalogs 
http://ns.inria.fr/active-tags/active-catalog/active-catalog.html that I 
have implemented (partially) http://reflex.gforge.inria.fr/

One of the main ideas is to add to the catalog entries a selector 
(actually a QName) that helps the catalog manager to return the right 
resource (a schema, an XSLT stylesheet, an external identifier, etc, or 
even a catalog or a selector) according to the requester: an XML parser 
that have to resolve public or system IDs would ask the catalog manager 
with the "external identifier" selector, and an XSLT processor with the 
"stylesheet" selector, etc, and you can have a specific component that 
would use its specific selector.

RefleX uses Active Catalogs intensively, and I admit that I have already 
think about a catalog for mapping usual prefixes to namespaces URI with 
the relevant selector ("Usual prefixes" means "xhtml" for XHTML, "svg" 
for SVG, "xsl" for XSLT etc). But the purpose was not the same: I had 
somewhere in the code something that generates prefixes(***) and those 
prefixes are generated randomly, whereas I could rely on "usual 
prefixes" if necessary.

(***) (in order to create what I call a canonical XPath where every step 
that refers to a qualified name must be done with a prefix that is not 
necessary present in the document, or that is overridden in the elements 
hierarchy)

> 
> The main benefits you get are
> (1) your XML documents are simpler and smaller
> (2) it's easier to remember the xin file than a mass of URIs
> (3) you dereference xin files and cache them -- they are not names --
>     so whether there is a trailing slash or not, whether there's a #
>     at the end, whether characters are escaped or not, makes no
>     difference, an architectural improvement.
> 
> The main downside is that it [expletive deleted], but maybe it [expletive deleted] less than
> the status quo (and in any case [expletive deleted] isn't always bad...)
> 
> A secondary downside is that when you rely on something not
> ubiquitous, you risk losing some interoperability.
> 
> My question is, is anyone interested and does it sound useful?
> Does anyone want to help me experiment with implementations?

RefleX is in essence almost "XIN ready" !
(optimistic view: I was just thinking about the mapping in the catalog 
and the lookup machinery in the implementation)

<cat:catalog xmlns:cat="http://ns.inria.org/active-catalog">
   <cat:resource name="svg" uri="http://www.w3.org/2000/svg" 
selector="xml:xin"/>
</cat:catalog>

> 
> It's not inconceivable to me that such a thing could get into a
> future version of XHTML, and/or get fairly widespread support,
> if it was useful.
> 
> Liam
> 


-- 
Cordialement,

               ///
              (. .)
  --------ooO--(_)--Ooo--------
|      Philippe Poulard       |
  -----------------------------
  http://reflex.gforge.inria.fr/
        Have the RefleX !

• References:
  • XIN: XML implicit namespace definitions
    • From: Liam Quin <liam@w...>