Re: [xml-dev] Mailmen, POST, Intent, and Duck Typing

[adasal <adam.saltiel@gmail.com>]

So, putting this together with

> I won't even mention the time canonical schemas were modified in-house
> by one of our partners to add "missing" field length validation and then
> the ensuing dismay when we tried to give them new ones that were
> structurally equivalent (without starting this argument ;), but in which
> the namespace had been altered slightly, and, of course were again
> "missing" the field sizes.  Ok, I mentioned it.

this

 We use markup over delimited ASCII
 because we want to put more semantic hints as to the producer's
 intent.   If we want stronger hints, we go
 to a language like RDF to provide stronger linking among the signs.
 If we want to send our intent and ensure
 it can't be misinterpreted

are you saying that a possible solution to the problem of evolving schemas is  the use of meta data?
This seems so obvious, and yet, in practice it is not being done apart, I suppose, from where it has to be, when the schema repository is sufficiently large for people to think seriously about how it is handled. In other words, it is not being done in everyday development AFAIK. Moreover, in themselves, this is what RDF OWL and other semantic languages are, richly self describing, but they seem not to be used just for that, whereas I see it as a first step towards more ubiquitous use. I'm sure I have missed something (several things) but, to be clear, what I mean is the situation where the producer just means to describe fields in a document, their type, relationship to one another and so on, while the consumer can take this description and seperate it from any particular set of data it wraps, that is compute on the description independantly from the data it contains. I guess, use RDF to do RDF. I think I understand that this is what is done. Usually the referant is a resource, for instance the often cited example of a song with references to composer, and album art. But I mean references to a class "text field" with various attributes. This would make schema manipulation and usage operate on a completely different footing to how it does within the confines of XML/XML Schema.
Adam

On 28/02/06, Andrew S. Townley <andrew.townley@bearingpoint.com> wrote:

Actually, Len's comments remind me of a discussion I had with a member
of my team about how to design a non-Web services XML message
processor.  There are about 10 items in the message (which can be quite
large) which are of interest to the program.  What I wanted him to do
was somehow (I really didn't care how... SAX, XPath, XQuery) write the
tool so that it would only process those bits and then get out of the
way (there is a transformation step too, but speed wasn't really
critical, so XSLT would've been a reasonable approach).

What did he do?

Yep.  XMLBeans.  "Works great!" was the response to my somewhat
horrified, "you did what??"

I didn't want the implementation of the tool to give a toss about the
message, but now if anything changes, we've got to recompile/redeploy.
Of course it was quicker/easier to develop, but I'm not really sure
about the TCO.

This pretty much proves Len's point, I think.  No matter how many
options for flexibility exist in isolating the parts of the vocabulary
that really matter for a given application (assuming that set is
significantly less than 50% of the document), there will always be
people with fancy tools and magic buttons to render all that flexibility
moot.  From Len's description:  pragmatism in action.  Of course, that
means dealing with the inevitable change is someone else's problem...

I won't even mention the time canonical schemas were modified in-house
by one of our partners to add "missing" field length validation and then
the ensuing dismay when we tried to give them new ones that were
structurally equivalent (without starting this argument ;), but in which
the namespace had been altered slightly, and, of course were again
"missing" the field sizes.  Ok, I mentioned it.

I think that the vast majority of the members of this list wouldn't have
done that, but these sorts of problems always seem to crop up no matter
how hard you try to prevent them.  Aside from forced subscriptions to
the list and a whack upside the head with a couple of Rusty's books ;),
I'm not sure what the best solution is.  I think we're a bit out
numbered...

ast

On Tue, 2006-02-28 at 14:26, Bullard, Claude L (Len) wrote:
> I don't think it weird but I'm not surprised by that.   It is pretty
> simple.   We use markup over delimited ASCII
> because we want to put more semantic hints as to the producer's
> intent.   If we want stronger hints, we go
> to a language like RDF to provide stronger linking among the signs.
> If we want to send our intent and ensure
> it can't be misinterpreted, we package up the
> intentions/functions/methods with the data and send that.
>
> So once again, if there is to be a pragmatic layer, and I assume that
> means something codified in the
> program or code that flips the bits on the machines, then other than
> sharing a philosophy of meaningful
> utterances, norms and affordances, how would one communicate those
> utterances, norms, and affordances?
> IOW, what is above semantics?   Pragmatics.  How do we implement
> pragmatics?  Objects.
>
> Other means may be possible but that is a first position.   Even an
> interpreter for a set of RDF assertions
> attempting to evaluate a text requires a functional contextualizer.
>
> len


***************************************************************************************************
The information in this email is confidential and may be legally privileged.  Access to this email by anyone other than the intended addressee is unauthorized.  If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************