[
Lists Home |
Date Index |
Thread Index
]
bry@itnisk.com (bryan) writes:
>>Is that your translation of DSML's "Representing directory structural
>>information as an XML document"? That's not what I'm looking for, in
>>any case.
>
>No, since you said you didn't mean DSML, I was thinking more along the
>lines of xml documents that could be integrated in any directory view
>as further description of that view, i.e. not as subdirectories of the
>directory. Which I didn't think you meant either, which was why I
>asked if what you meant was number 2.
Then I guess I meant number 2. I thought I'd made it pretty clear that
#1 might be exciting for some people but wasn't what the thread was
discussing way back when.
>>>If this were a GUI, all elements would be represented as folders,
>>>attributes and text nodes as files
>
>>Not necessarily represented using folder icons, but treated like a
>>folder as something you can explore further, yes.
>
>Well I'm just wondering what you, or other people would want the
>attributes, text nodes, and other non-element nodes to be represented
>as? I'm supposing that you want a generic xml solution, no matter what
>xml file it is it will be loaded and displayed in the same way.
I don't pretend to have solved the GUI issue, but do think there's room
for filesystem/browser integration that's a lot smarter than (for
instance) Active Desktop. Functionally, I'd like to be able to manage
groups of XML documents in a filesystem using paths that include both
filesystem path information and XPath information.
Building a graphical interface to that approach is a tough problem,
especially because of attributes, but I don't think that interface
problem has to be solved before the underlying approach becomes useful.
>>The attributes I'd want to add to the filesystem are already in the
>files >themselves,
>
>so when you speak of adding attributes to the filesystem are you using
>attributes like in this fork thread:
>http://www.xent.com/pipermail/fork/2003-May/021171.html
>
>or are you talking about xml attributes;
I'm talking about XML attributes in the file. I was making a contrast
between "filesystem attributes" and "XML attributes", and saying that I
preferred the latter.
> is there meant to be a
>relationship between the two?
I don't think so, but I'm sure someone will be happy to create such
relationships and even redundant data for optimization if and when this
ever takes off.
>I'm sorry I'm just thinking of this in a GUI way,
Perhaps you need to stop thinking about this in a GUI way, at least
until some foundations get built. (Five years on, and not much has
happened, so maybe it just doesn't matter anyway.) Maybe I should have
avoided graphics in my article entirely?
>you go to any xml
>file in a directory, you open that and this file is presented as a
>subdirectory, what exactly would the relationship of attributes in
>the xml file be in this directory 'created' from the xml file?
I'm not proposing that anything be 'created' - I'm proposing that we be
able to navigate two sets of hierarchical structures using the same
basic tools. I'm not sure what you're asking.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
