First, no, I'm not even close to done with the Wolfram book, but it
is clear that it is going to take longer than I thought, and given my
own track record wrt getting back to unfiinished business, I decided
to stay with the approach of annotating as I go, rather than pushing
through a first reading to get the gist then going back for depth.
That said, I can't let other work languish while I'm busy deciding
whether this book is going to necessitate a change in my thinking or
our work taken separately or together.
So, as we, in HumanMarkup, get ready to launch into Len's proposed
experiment with a semiotic processor, I offer this article:
A question I think we need to ask is: Do we need to specify a
processing order within a semiotic context for HumanMarkup in an a
priori fashion for any application document using HumanMarkup?
I have long thought that some sort of preflighting of resources for
any given application-specific xml operations on the web needs to be
addressed even before or perhaps simultaneous with parser validation
of a document invoking those operations. Our position on this needs
to be noodled out before we start thinking about how or whether
HumanMarkup-based or -supported applications documents SHOULD order
parsing of applications document-specific operations.
In practical terms, what this means is that, for example, a web
service being requested by an end-user needs to have all connections
tested for reliability, security and availability before an
end-user's HumanMarkup-enhanced personal preferences information is
passed, and that needs to occur immediately after any single-sign-on
identity authentication, which takes place first before a connection
to a service is confirmed. I mention this in concrete terms so that
we know that we are talking about clearly concrete issues, and not
just a theoretical experiment. So, we need to cast the experiment so
that it tells us the answer to these questions, in addition to more
purely intra-HumanMarkup concerns.
I am copying this to the Web Services for Interactive Applications TC
and my contact at HR-XML.org so that they know that these issues are
being discussed here.
There are implications in these considerations as well for XMLP in
the sense that whatever it turns out to be, we will need to make sure
that our requirements for that protocol are made known.