- From: <bugzilla@jessica.w3.org>
- Date: Mon, 05 Dec 2011 18:22:59 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14932
--- Comment #9 from Erik Wilde <erik.wilde@emc.com> 2011-12-05 18:22:56 UTC ---
(In reply to comment #8)
> > > Web friendliness is important. Let's make sure we don't achieve that at the
> > > expense of data integration.
> >
> > i don't see how a more orthogonal design of web-oriented functionality would
> > create problems for data integration. on the contrary, data integration often
> > will be based on being able to take full advantage of web architecture, and if
> > i don't have control over, for example, HTTP methods and headers, then there
> > are a lot of things i just cannot do with data that is exposed on the web.
> I think we should start with requirements and use cases, both for existing
> applications and those you envision.
that's what i was trying to do, but maybe this bug tracker isn't the best
place? i am looking at using XQuery in a service-oriented environment where it
is used to both expose and consume web services. for this to be well-supported,
we need to match how web architecture works, and how XQuery supports the key
parts of it, which at a high level ob abstraction are identification,
interaction, and representation.
> You ask this about a few items - I think that's a question we would have to
> look at across existing implementations. The ones I have worked with tend to
> use collection() for persistent XDM or relational tables, and use doc() for a
> variety of things.
> I would not be at all surprised if some implementations use doc() in the same
> way implementations I have been involved with use collection().
may doc() and collection() would not be the best things to change to be better
in line with web architecture, then, because they are well-established and
implementations already have certain ways of how they implement them. in that
case, having functions for
- handling identifiers,
- dereferencing identifiers, and
- handling representations
might be a better way to approach this, and while for some of these there
already are functions (such as resolve-uri()), for others, there aren't.
> DataDirect's data converters (which I did not specify) use URIs to specify a
> conversion, conversion parameters can be specified as part of the URL:
> doc("converter:Base64:newline=crlf:encoding=utf-8?file///w:/myfiles/base_to_xml.bin")
wow, that's actually quite impressive. this pushes a lot of functionality into
proprietary URI schemes, essentially turning those into a place where vendors
then put their extensions. i wouldn't say that from a language design point of
view, that's the best way of supporting this extensibility pattern.
> I honestly don't know what all implementations do. I think we would have to
> find out. We have to be careful if we forbid anything that was previously
> allowed. Sometimes we do that, but very carefully.
absolutely agreed. and i am not suggesting to disallow those things. but maybe
we have an opportunity to revisit how essential parts of web architecture are
being handled, and can try to come up with a different way how those are
exposed in XQuery, instead of pushing everything into proprietary URI scheme
behaviors.
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 5 December 2011 18:23:02 UTC