- From: Vasil Rangelov <boen.robot@gmail.com>
- Date: Thu, 9 Aug 2007 01:08:29 +0300
- To: <public-xml-processing-model-comments@w3.org>
Hello. First of all, I'd like to say "thank you" to the WG for accepting my p:(directory-)list suggestion. Now, I have some comments about it ^_^. I liked (almost) all of the changes that were made prior to this step's addition in the draft. In particular, the "depth" option seems like a much better idea than "recursive" one to me (I wish I thought about it :D). I think the whole paragraph " When a directory entry is a subdirectory, that directory's entries are not output as part of that entry's c:directory. A user must apply this step again to the subdirectory to get that directory's entries. " Should be edited to respect the recursive option (or the "depth" if that is going to make it). Something like: " When a directory entry is a subdirectory, that directory's entries are not output as part of that entry's c:directory, unless the recursive option is set to "yes" or "true". A user must apply this step again to the subdirectory to get that directory's entries. " OK. I guess that's not good either (I sure didn't understood a thing), but you see the point. About symbolic links. I don't think they should be treated. This step should map the file system, not the server system. In fact, I'm not sure if the later could be indexed to begin with. I mean, web servers just return an HTML page (in their own format) with links to the files, not metadata about folders in an RDF like fashion, right? Still, I guess c:other is a good thing. BTW, should extension information be added in other namespaces to avoid conflicts, or are implementations free to place such information without a prefix as well as long as it's not in conflict with a standardized attribute? I think they should only be allowed to add such in their own namespaces, as who knows what later versions might standardize for c:directory and c:file. Regards, Vasil Rangelov
Received on Wednesday, 8 August 2007 22:08:44 UTC