Le 6 févr. 08 à 22:52, Alain Frisch a écrit :

> The problem with expanded names is that it makes it quite tedious to  
> pattern-match on element/attribute names (uri are long!).

Agreed.

> Another option is to let the client provide a mapping from uri to  
> fixed prefixes. (PXP can do that kind of prefix normalization.)

In xmlm you can do that yourself on input when you get callbacked and  
do the reverse translation just before outputing
start tags. Of course this means more work for the client, but it  
makes the basic interface simpler and it allows the client
to use variants instead of simply shorter prefixes.

> It is also a good idea to be able to parse XML documents that conform
> to the XML spec but not the XML Namespaces spec.

But don't you automatically get that ?

A document that has no xmlns namespace declarations and no prefixes if  
parsed according to the xmlns spec will result in names with empty  
namespace names.

The other problem I see is if there are external prefix declarations,  
but for that, as I did for external entity references, I have a  
callback that allows you to bind an undeclared prefix to an uri.

> What about something like that:
>
> type name = string * [`N of string * string|`U of string * string|`X]
[...]

Too heavy weight for my taste. With xmlm I try to give a reasonable  
default for xml IO, not the full blown complexity. So I think going  
with qualified names only is ok, the client can transform its own way  
if it whishes (e.g. uri replacement).

> Also, it is necessary to give the client a way to know the namespace  
> bindings in scope at any node. Some XML languages like XML-Schema  
> need this information. A possible way to do it is just to keep the  
> xmlns declarations as regular attributes.

I was planning on keeping the xmlns declarations, but I ignored some  
languages actually *need* this information, what is it used for in xml- 
schema ?

Thanks for the comments,

Daniel