On Apr 12, 2006, at 2:43 AM, Brad Neuberg wrote: (01)
> Hey Les, great to see you on the list; I've seen your XOXO
> outliner, its very cool. Can't wait to hear your insights and input. (02)
Thanks - hopefully I have some insights suitable as input :) (03)
> I'm bouncing back and forth between representing our HyperScope
> structure between an XHTML microformat such as XOXO and between a
> non-XHTML one such as OPML. I created an early basic prototype
> exploring Augment's viewspecs with XOXO, but I'm leaning more
> towards OPML these days.
>
> The chief reason in favor of OPML at this point is due to Augment's
> very sophisticated and complicated addressing scheme; it turns out
> that resolving our addresses is easier when used on an OPML
> document on the client-side using XPath expressions, and the fact
> that the OPML DOM in the browser (when XML comments are removed) is
> a one to one mapping to the hierarchical structure of Augment files
> so it is easy for me to resolve structure information. (04)
Yeah, that's one thing that causes me to grumble with XHTML
microformats - addressability via XPath. Take the attribute
collection microformat based on the <dl> element. You need to walk
through a list of <dt> name / <dd> value pairs and mind your
siblings. I really like microformats for the broad number of
variables they solve in the web equation, but they're certainly not
aimed at direct simplicity in processing. (05)
OPML, on the other hand, looks like an explicit tree of loosely-
typed, attributed nodes. Dave's 2.0 spec [1] has really nailed this
down, I think. Very simple XML, easily walked with XPath. It can be
converted fairly easily to and from a constrained profile of XOXO
without a loss of fidelity - at least, none that I've found so far.
That's part of what I've been playing with in my new reboot of my
XOXO outliner code. (06)
I'm just starting to soak my head in Augment structures, but the
comparison to OPML was one of the first things that popped up in my
head - so I'm glad that maybe I'm on the right track! (07)
[1]: http://www.opml.org/spec2 (08)
> Augment is extremely polymorphic, when means a single command, such
> as the Jump command to resolve some object, can act on many
> different kinds of things. In essence, most commands can operate on
> Augment addresses, which are able to pretty much reference any
> arbitrary object you could imagine, including apply views to the
> resulting document returned. Here is a sample address showing
> different abilities:
>
> <foo.com, neuberg, hyrequirements, 1.dl:d;"TODO:";>
>
> This is a sophisticated address that does the following... (09)
Wow, so that's what's happening in those addresses. I'm still
catching up on them, since they seem a bit opaque to me so far - but
I had some sense that they were super-granular and had that filtering
capability built in. Sounds a bit like a major superset of what
XPath offers for XML. (010)
I'm sure I'll have loads of questions at some point, but one burning
question I've had is: Are Augment addresses stable in the face of
continued editing on documents addressed? I seem to recall this
being addressed in Purple Numbers, but I never wrapped my head around
it. I've always wondered about that in general. (011)
> I'm just starting to learn the kinds of amazing things you can do
> with this by watching Douglas work. (012)
So far, my mental model of this stuff is akin to what I've seen
masters of Vim accomplish, only better. And it makes me want a
chording keyboard :) (013)
--
l.m.orchard@pobox.com
http://www.decafbad.com (014)
--
This message is archived at: (015)
http://blueoxen.net/c/hyperscope/forums/cgi-bin/mesg.cgi?a=dev&i=4976C1F0-9BD9-4E8A-94DC-F1AC3FD5FA2C@pobox.com (016)
|