W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > January 2008

Re: A few items cherry-picked from comment #54

From: Nikolay Fiykov <nikolay.fiykov@nsn.com>
Date: Wed, 30 Jan 2008 13:30:36 +0200
Message-ID: <47A05FDC.7090400@nsn.com>
To: public-xml-processing-model-comments@w3.org


> 1. Should we add support for exclude-prefixes in serialization?
>   
Having extra namespace declarations does not hurt when comes to machine 
processing the xml files.
In my case though, there are numerous instances when the xml documents 
are actually pretty-printed and showed to real people. Then any kind of 
data garbage is very disturbing. Actually it is an requirement not to 
happen.
Besides, it is already presented in xslt, does one need to run an extra 
transformation just to use serialization?
> 2. Would the 'path' attribute on p:directory-list be better named 'uri-path'?
>   
I'd say even named only "uri". For example "jar:...", "file:...", 
"ssh:..", "http:.." and any other URI provider would be very much usable 
to list directories. There are filesystem-based use cases provided by 
non-native handlers, like cvs/svn/clearcase for instance.
Of course, URI providers are OS-specific, I'd assume that the spec can 
mandate only "file:", rest could be processor specific.
> 3. Should we add a scheme to p:label-elements that generates an ID by
>    evaluating an XPath expression?
>   
Actually I though of allowing completely free XPath expression, 
generate-id is only one possible usage.
In general label-element in its current form is very much xml:id 
oriented (i.e. uniquely generated values, count-elements).
The name though "label-elements" suggests something much broader. And I 
have already plenty of use cases which could fail into that category. 
The differences with the current definitions are:
- generate multiple attributes per labeled element
- use genuine XPath notation to generate attribute values

Nikolai
Received on Wednesday, 30 January 2008 13:27:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2008 13:27:38 GMT