Version française
Home     About     Download     Resources     Contact us    
Browse thread
xmlm and names(paces)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Bünzli_Daniel <daniel.buenzli@e...>
Subject: Re: [Caml-list] xmlm and names(paces)

Le 7 févr. 08 à 09:13, oleg@okmij.org a écrit :

> It should be mentioned that the prefixes of qualified names cannot
> just be alpha-converted. It is quite common to see the following,
> quoted from http://www.w3.org/TR/xmlschema-0/
>
> 	<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>         ...
> 	  <xsd:element name="comment" type="xsd:string"/>

Argh ! I now understand Alain's comment about the need to keep that  
information. This is a complete misuse of the namespace recommandation  
which says nothing about binding pefixes in attribute and character  
data. The w3c is really hopeless.

> One may really wonder what kind of people wrote all those voluminous
> XML recommendations.

You tell me.

> So, ideally one may wish to keep the original prefix (in addition to
> its corresponding URL). It is also reasonable for a user to specify a
> `shortcut'. Unlike the prefix, which is chosen by the author of the
> document, a shortcut is chosen by the person who invokes a parser.

As mentionned in my previous email with xmlm you can do that by  
yourself since all the info is there and you have full control on the  
parsing result. However for the aformentionned case this may mean a  
lot of work. On the other hand xml schema seems to be seen as a broken  
technology (even the xml spec editor says so iirc). So the question  
is, is it worth complexifiying the interface to facilitate the parsing  
of this obviously broken and marginal (is it ?) case.

> Incidentally, some of the design decisions of SSAX (despite being
> produced by an enemy) might be pertinent to this discussion.

Thanks for the link, I will have a look at it (functional programming  
languages are no enemies).

Best,

Daniel