Re: xmlFunctions-34

Paul,

mea culpa.  I thought I had done that one, and indeed I did write a draft
but my laptop is dead and I fear the draft with it.  I was hanging on
until I had time to reserach the XML Core work which people had refered
to.  (It is, as you say, the processing model work.)
Here is a quick attempt to duplicate it in time for your f2f.

The gist of the issue is that there are a number, and will be more, XML
namespaces which rather than being applicatoins encoding some
applicatoin data which will be interpreted outside the XML world,
(like financial transfer information, say),
are encodings of information which is to be processed and then
reinterpreted again within the XML world.

Examples are

- XML Encryption
- XInclude
- XSLT templates

(The latter is not in the spec couched in this way at all - an XSLT template
is officially to be interpreted as shorthand for the use of style sheet.
I aurgue that it loses a lot from being couched in that way - it would
be better described as a function)

These ideas are discussed in a rambling
http://www.w3.org/DesignIssues/XML

The issue is that there is no framework or convention is currently defined
which allows specs like the above to be defined in such a way
as to apply to any XML application, and also to be mixed.

Yes, it is a processing model question, but it does not involve
the definition of a new langauge for expresing combinations of
different XML processing.   The issue is a need for a default
processing model which admits of both transform-like
things as a bove, which I have called XML functions, as well as
end applications.

The requirement for independent design of XML functions
imposes some things on the processing model.
It requires the procesisng model to be top down recursive
in the tree.
This requires that XML functions ONLY return new content to
replace themselves, without reference.
There has to be some thought about how to constrain
XMLT transforms which make refernce outside their
own elements.

So the requirement is that the above and other XML functions
can be defined without reference to or from the  applications
which are going to use them. There is a requirement
that the conformance clause of an XML function spec should
work when conmbined with the conformance clause for
an application, without further architectrueal work.

So, for example, an application conforming to XML encryption
and conforming to SVG would be able to receive an XML
document with any parts encrypted, decrypt them, and
treat it as an SVG document.

Implications? There are in fact a few
software architectures whcih can achieve this.  It has
implication that application-schema-validity applied
to the document with is functions elaborated.

So,  it is a cross-applictaion XML architecture question.
I am sorry this is late (and rushed) and hope the group
can make sense of my attempts to outline the issue at the
face to face meeting next week.

It would be nice to have an understanding of how to process these
thing sin a consistent (powerful and useful) way, to investigate how
it meshes with the existing specs, and have it ready for new ones.

Tim


----- Original Message -----
From: "Paul Grosso" <pgrosso@arbortext.com>
To: <www-tag@w3.org>
Sent: Thursday, February 27, 2003 10:09 AM
Subject: xmlFunctions-34


>
> At 20:54 2003 02 26 -0500, Ian B. Jacobs wrote:
> >Minutes of the TAG's 24 Feb 2003 teleconf are
> >
> >[1] http://www.w3.org/2003/02/24-tag-summary
> >
> >-==============================================
>
>
> >     * [23]xmlFunctions-34
> >          + Action TBL 2003/02/06: State the issue with a reference to
> >            XML Core work. Deadline 17 Feb.
>
> >     [23] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
>
>
> Did I miss something, or is the above ACTION still pending?
>
> I am guessing that the reference to "XML Core work" above
> might refer to our "XML processing model/pipeline" task.
> If so, I note that the WG is having trouble making progress
> on this topic, but we plan to discuss it during our f2f
> next Monday and Tuesday.
>
> If, in fact, the above TAG issue does have any relation to
> this topic, it would be useful to have the clear statement
> of this issue before the end of this week so that it could
> be part of our discussions.
>
> paul
>

Received on Friday, 28 February 2003 13:51:40 UTC