[xmlschemata] Another (too much early?) idea for xvif...

Hi Eric, hello all,

1. Enthusiasm

As I have recently posted to the [XMLFR; xml-tech] list, I must say that I was
*very* enthusiastic, right from the start, about the approach chosen by Eric's
[xvif] initiative.

2. Another (weird, sorry ;=) idea

Now as a try to be constructive in the same direction (and putting apart my
excitement the best I can ;=) I would like to propose a small contribution of
mine for discussion.

Note this is merely an "emerging" idea, and of minimal discussion priority,
though: be sure not to miss this note (1) below for my opinion about it... Well,
anyway, I hope it's interesting enough in contemplating (future) xvif dev.

Currently, I can only afford in trying to put it as simple as I can, through
adaptation of current xvif's informal description and a syntax example, even
w/out any other piece of explanations aside - if my idea is any good, I guess
what follows will suffice to express it, solely by the means of having you to
catch it... by yourself (no kidding! ;=)... I hope; and also about what one
could build upon (2)...

OK, then here it is.

2.1 Preliminary :

I'm just considering [that other idea], borrowed from [RDDL], but adapted to
xvif concepts and parlance.

Thus, I propose to insert sth like the following in the strawman, "where
appropriate" :

"[...]Generally, the semantics of an <if:transform...> construct is to transform
a node-set *with* one nature into another. We may use a convention that the
purpose of an <if:transform...> is the nature of what results[...]"

2.2 Elsewhere, a possible adaptation of current xvif's informal description,
together with an example of my proposal's instance syntax (most simple change,
almost trivial ;=) :

(Updating the corresponding paragraph in the strawman)

"[...]The description is performed as a 'push' pipeline of transformations where
if 'x' is the context nodeset, and 'n' its context nature URI, the result 'y' of
the transformation T, of (non-contextual) purpose URI 'p', applied on 'x' (ie 'y
= T(x)' ) the transformation is defined as:

The pair (x, n) formed with the context nodeset (x) and the context nature URI
(n) is defined by the host language here
<if:transform
  type='URI indentifying the nature of T'
  rddl:nature='n'
  rddl:purpose='p'>
<if:apply>
  Implementation of T
</if:apply>
</if:transform>
The result of the transformation is the pair (y, p) where 'y = T(x)' is the
(new) context nodeset and 'p' is the (new) context nature URI here[...]"

And so what? Well, let's say simply that one could then find interesting to
"query" about occurrences of these rddl:nature and rddl:purpose attributes
amongst xvif instances, relating them together with other properties : notably,
that thoughtfully designed, already! existing 'type' attribute of Eric...

3. Feedback :

... Got the idea, you too? (Take your time... ;=)

OK, here's a hint : wouldn't be interesting to have such a capability for
supporting a so-called, say, "discovery of semantics-oriented properties of
<if:transform...> steps in (pipeline-based) validation chains" expressed with
xvif?

Does this make any sense? ...to be continued?

4. Why chosing "rddl:nature" and "rddl:purpose" - why not "xlink:role" and
"xlink:arcrole" ?

As I understand them, I think that "xlink:role" and "xlink:arcrole" attributes
effectively find their best place in applications such as [RDDL], with its
"[rddl:resource]" element; here, we should avoid confusing the user of both RDDL
and xvif; thus, that choice of attribute names for xvif.

(Thanx in advance for your criticism, opinion, conceptual/formalization
cleaning, etc ;=)

5. Notes :

(1)
Please note, however, that I am perfectly conscious that what you read above is
*very likely* to be... far too much early.

So that, I do not pretend to have raised here an (even minimally) important
topic for now, as we are only at the beginnings of xvif.

Instead, please just consider I envision this *could* be something interesting
to remind to, provided we would want to extend xvif's range of
"application-gluing" capabilities, as soon as we have it mature enough w.r.t all
of its currently defined design goals/choices (which we all know to be the only
real current priority, of course)

(2) to be elaborated later (in particular, relatively to other [SW] topics), if
any positive feedback

Best,

Cyril

mailto:Cyril@cjandia.com
http://www.cjandia.com/

[XMLFR; xml-tech]
  http://xmlfr.org/listes/xml-tech/

[xvif] ("strawman")
  http://downloads.xmlschemata.org/python/xvif/xvif.html

[that other idea] in :
  http://www.rddl.org/purposes/software

[RDDL]
  http://www.rddl.org/

[rddl:resource] (element)
  http://www.rddl.org/#resource

[SW]
  http://www.w3.org/2001/sw/

--CJ
Received on Fri Jun 21 17:55:05 2002