Re: [Simple] Re: Other MIME type than xcap-el/attr

[Jari Urpalainen <jari.urpalainen at nokia.com>]

On Fri, 2006-02-10 at 07:36 -0500, ext Jonathan Rosenberg wrote:
> inline.
> 
> Jari Urpalainen wrote:
> 
> > Inline --
> > 
> > On Wed, 2006-02-08 at 16:57 -0500, ext Jonathan Rosenberg wrote:
> > 
> >>The intent was that its not meant to be extended, and that nothing else
> >>would be used. Do you have a use case or need for something else?
> >>
> >>Thanks,
> >>Jonathan R.
> >>
> > 
> > well I had another impression. E.g. with multi-insert one would use
> > multiple elements in the body, would it be the same content-type than
> > xcap-el+xml, for example ?
> 
> Yes; it would just have multiple elements.
> 
hmm. while I agree that this is certainly possible with this weird
xml ;-) it is imo worth a note somewhere because in general this is not
possible.

> > Anyhow, I don't much care if some new
> > content-types are defined by some new extensions, because they don't
> > break the base spec in anyway, imo.
> 
> They don't; my point though was that unless you were doing something 
> substanially different, xcap-el+xml really ought to suffice. I'd still 
> like to understand what the use case was around the question.
> 
> 
>   That is, you'll negotiate response
> > type with Accept-header and even in some cases you might use request
> > body as well and XCAP capabilities doc may list this extension tag.
> > Although XCAP isn't an XML database or something like that, a really
> > cool extension would be, for example, XQuery like requests over docs. 
> 
> Right - like I said, unless you're doing something pretty radically 
> different, xcap-el+xml will suffice.
> 
XQuery might be radical, I'd say it is complex and computer intensive,
but I would not like to forbid anticipated possible future extensions,
if there's no real technical reason behind prohibiting them.
> 
> > So
> > I don't see a problem for a future extension to define some new
> > semantics with new mime-types (although I don't have an intention to
> > propose something now, no ;-)). Also one could argue that some BNF
> > extensions (which are now explicitly allowed) are useless without the
> > ability to have new mime-types as well.  
> 
> There I disagree. The new extensions to the URI are meant to allow 
> different ways of selecting elements and attributes, but the net result 
> is that what comes back is still elements and attributes.
> 
> -Jonathan R.
> 
In addition to elements and attributes (where element patching covers
undoubtedly over 90 % of the use cases, in general), text, comment,
processing instructions and namespace declarations could be allowed with
an extension specification as well.

As an example, namespace declarations could be added with a namespace
axis selector:
PUT ...~~/root/namespace::prefix   "uri:test"
A very similar (and trivial) solution than attribute selections. The
biggest difference being there's no abbreviated selector.

Text nodes could be allowed as well:
PUT ...~~/root/text()   "new replaced text" 

What is difficult with them (as well as with elements, comments and PIs)
is the exact positioning of new nodes (if there are several siblings).
One really unambiguous solution is to use XPath "node()" function within
predicates. "node()" selects all child nodes of the context element,
i.e. child text, elements, comments and PIs. So a request like:

PUT ...~~/root/node()[3][self::text()] "added or replaced text at node
position 3"

will require that the third child node of <root> must be a text node. If
the current 3. node is not a text node, it will be added there. This
could be used also to maintain pretty printing style. Comments could be
added similarly, PIs have a name. Certainly there are drawbacks, e.g.
blind updates not possible because of positional predicates, some
complexity etc. But I really don't see a point for disallowing these
kind of possible future extensions. Sure they are not amongst the most
needed features, but adding these will not break the base spec anyway. 
br,
Jari


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple