has XML, XSLT, XQuery and XML Schema have reached a stable state

[Mukul Gandhi]

Hi all,
   I was just wandering, if W3C thinks that apart from specifications
like HTML and HTTP, specifications like XML, XSLT, XQuery and XML
Schema have reached a stable state, and no further innovation is
required with these new web languages, other than completing the
current ongoing specification work, on draft and CR specs?

Can the web community expect the specifications like XML, XSLT, XQuery
and XML Schema to be freezed like HTML and HTTP in near future?

It seems to me, the new things that W3C is pursuing these days are
mobile web, markup compression etc.


--
Regards,
Mukul Gandhi

[Julian Reschke]

Mukul Gandhi wrote:

> Hi all,
>    I was just wandering, if W3C thinks that apart from specifications
> like HTML and HTTP, specifications like XML, XSLT, XQuery and XML
> Schema have reached a stable state, and no further innovation is
> required with these new web languages, other than completing the
> current ongoing specification work, on draft and CR specs?
>
> Can the web community expect the specifications like XML, XSLT, XQuery
> and XML Schema to be freezed like HTML and HTTP in near future?
>
> It seems to me, the new things that W3C is pursuing these days are
> mobile web, markup compression etc.

HTML and HTTP do not appear frozen to me.

BR, Julian

[Mukul Gandhi]

On Wed, Oct 21, 2009 at 9:54 PM, Julian Reschke <julian.reschke@...> wrote:
> HTML and HTTP do not appear frozen to me.

I could see, work is still continuing with HTML. I am just curious,
what further can community expect, for HTTP evolution? Isn't HTTP 1.1
sufficient for us?


--
Regards,
Mukul Gandhi

[noah_mendelsohn]

Mukul Gandhi writes:

> Isn't HTTP 1.1 sufficient for us?

I don't think one ever knows for sure in advance, and for that reason I'm
not entirely comfortable with your question.  Certainly HTTP is an
extensible protocol.  People do discuss new headers from time to time.
When HTTP 1.1 was created, it was to better meet the performance and other
needs of the Web traffic that was being supported.  Who knows?  Maybe in a
few years it will be decided that an HTTP 1.2 or even HTTP 2.0 is needed,
perhaps to better support something like video streaming.  Certainly, the
fact that HTTP is so widely deployed tends to mean that major changes tend
to impact a lot of people and implementations, and that somewhat raises
the bar.  The HTTP 1.1 bis charter [1], which covers the next round of
work on HTTP, states:

The working group will refine RFC2616 to:
* Incorporate errata and updates (e.g., references, IANA registries, ABNF)
* Fix editorial problems which have led to misunderstandings of the
specification
* Clarify conformance requirements
* Remove known ambiguities where they affect interoperability
* Clarify existing methods of extensibility
* Remove or deprecate those features that are not widely implemented and
also unduly affect interoperability
* Where necessary, add implementation advice
* Document the security properties of HTTP and its associated  mechanisms
(e.g., Basic and Digest authentication, cookies, TLS) for common
applications

In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP
* Impact on existing implementations and deployments

Note that this does allow for removal or deprecation of features, and that
would in fact represent a change to the conformance requirements as far as
I know (albeit in areas that aren't widely or interoperably implemented
anyway).

Anyway, while it's possible in principle to state in advance that the
community is attempting to freeze a specification for all time, I think
that's rarely appropriate practice for the Web.  The Web will last a very
long time.  The sorts of content and applications it will have to support,
and the machines and networks that it will run on, will probably include
things we can barely imagine now.  I think all we can do is to try very
hard to build specifications that will adapt as gracefully as possible,
and to minimize incompatible or disruptive changes when new requirements
do dictate that the specifications should be revised.  Even mechanisms as
core to the Web as URI's are being gradually adapted or augmented with new
specifications like IRI.  I would expect the same to be true of HTTP over
time.

Noah


[1] http://www.ietf.org/dyn/wg/charter/httpbis-charter.html

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Mukul Gandhi <gandhi.mukul@...>
Sent by: www-tag-request@...
10/21/2009 07:42 PM
 
        To:     Julian Reschke <julian.reschke@...>
        cc:     www-tag@..., (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: has XML, XSLT, XQuery and XML Schema have
reached a stable state


On Wed, Oct 21, 2009 at 9:54 PM, Julian Reschke <julian.reschke@...>
wrote:
> HTML and HTTP do not appear frozen to me.

I could see, work is still continuing with HTML. I am just curious,
what further can community expect, for HTTP evolution? Isn't HTTP 1.1
sufficient for us?


--
Regards,
Mukul Gandhi

[Julian Reschke]

Mukul Gandhi wrote:
> On Wed, Oct 21, 2009 at 9:54 PM, Julian Reschke <julian.reschke@...> wrote:
>> HTML and HTTP do not appear frozen to me.
>
> I could see, work is still continuing with HTML. I am just curious,
> what further can community expect, for HTTP evolution? Isn't HTTP 1.1
> sufficient for us?

The HTTPbis working group currently is only chartered for maintenance
work. Does that make HTTP/1.1 "frozen"? I don't think so, because we
*do* change things that are broken.

Is HTTP/1.1 sufficient? That's a good question. We have discussions
about that all over the place, for instance about making a bidirectional
variant (ietf-hybi), about extensions for long-poll, or a major change
to the message format and many other things (-> Waka).

Best regards, Julian

[Mukul Gandhi]

Thanks, Noah for insightful remarks.
I agree to your comments.

On Thu, Oct 22, 2009 at 5:28 AM,  <noah_mendelsohn@...> wrote:

> Mukul Gandhi writes:
>
>> Isn't HTTP 1.1 sufficient for us?
>
> I don't think one ever knows for sure in advance, and for that reason I'm
> not entirely comfortable with your question.  Certainly HTTP is an
> extensible protocol.  People do discuss new headers from time to time.
> When HTTP 1.1 was created, it was to better meet the performance and other
> needs of the Web traffic that was being supported.  Who knows?  Maybe in a
> few years it will be decided that an HTTP 1.2 or even HTTP 2.0 is needed,
> perhaps to better support something like video streaming.  Certainly, the
> fact that HTTP is so widely deployed tends to mean that major changes tend
> to impact a lot of people and implementations, and that somewhat raises
> the bar.  The HTTP 1.1 bis charter [1], which covers the next round of
> work on HTTP, states:
>
> The working group will refine RFC2616 to:
> * Incorporate errata and updates (e.g., references, IANA registries, ABNF)
> * Fix editorial problems which have led to misunderstandings of the
> specification
> * Clarify conformance requirements
> * Remove known ambiguities where they affect interoperability
> * Clarify existing methods of extensibility
> * Remove or deprecate those features that are not widely implemented and
> also unduly affect interoperability
> * Where necessary, add implementation advice
> * Document the security properties of HTTP and its associated  mechanisms
> (e.g., Basic and Digest authentication, cookies, TLS) for common
> applications
>
> In doing so, it should consider:
> * Implementer experience
> * Demonstrated use of HTTP
> * Impact on existing implementations and deployments
>
> Note that this does allow for removal or deprecation of features, and that
> would in fact represent a change to the conformance requirements as far as
> I know (albeit in areas that aren't widely or interoperably implemented
> anyway).
>
> Anyway, while it's possible in principle to state in advance that the
> community is attempting to freeze a specification for all time, I think
> that's rarely appropriate practice for the Web.  The Web will last a very
> long time.  The sorts of content and applications it will have to support,
> and the machines and networks that it will run on, will probably include
> things we can barely imagine now.  I think all we can do is to try very
> hard to build specifications that will adapt as gracefully as possible,
> and to minimize incompatible or disruptive changes when new requirements
> do dictate that the specifications should be revised.  Even mechanisms as
> core to the Web as URI's are being gradually adapted or augmented with new
> specifications like IRI.  I would expect the same to be true of HTTP over
> time.
>
> Noah
>
>
> [1] http://www.ietf.org/dyn/wg/charter/httpbis-charter.html
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------

--
Regards,
Mukul Gandhi

[Mukul Gandhi]

Hi Julian,
   Thanks for your comments.

As far as I know, HTTP protocol is currently stateless (I guess,
cookies make HTTP stateful, but that's not statefulness on the wire,
but only via a user's hard-disk), and synchronous. Does anybody think,
a future version of HTTP should change these (one or both of them)
core HTTP features?

On Thu, Oct 22, 2009 at 12:11 PM, Julian Reschke <julian.reschke@...> wrote:

> The HTTPbis working group currently is only chartered for maintenance work.
> Does that make HTTP/1.1 "frozen"? I don't think so, because we *do* change
> things that are broken.
>
> Is HTTP/1.1 sufficient? That's a good question. We have discussions about
> that all over the place, for instance about making a bidirectional variant
> (ietf-hybi), about extensions for long-poll, or a major change to the
> message format and many other things (-> Waka).
>
> Best regards, Julian

--
Regards,
Mukul Gandhi

[Mukul Gandhi]

Here are some more thoughts, from me..

I think, HTTP essentially has request-response paradigm. The basic
HTTP protocol makes it synchronous. I guess, we have standards, that
allow HTTP data to travel over messaging systems. These newer message
oriented HTTP communication, make HTTP asynchronous.

Regarding statelessness of HTTP, I think cookies are the right way to
make HTTP stateful. But cookies require themselves to reside on user's
PC. I think, there is no other suitable way, than cookies to make HTTP
stateful.

It seems, I have myself found the answers to my questions...

On Fri, Oct 23, 2009 at 6:18 AM, Mukul Gandhi <gandhi.mukul@...> wrote:


--
Regards,
Mukul Gandhi

[T.V Raman]

Language experience over the centuries  teaches that languages
once having evolved to perfection die. Said differently, Latin
and Sanskrit are no longer spoken;-)

Let's  hope the XML family doesn't end up in  a similar state on
the Web --- though I fear that circumstances may have already
caused that to happen.

Mukul Gandhi writes:
 > Hi all,
 >    I was just wandering, if W3C thinks that apart from specifications
 > like HTML and HTTP, specifications like XML, XSLT, XQuery and XML
 > Schema have reached a stable state, and no further innovation is
 > required with these new web languages, other than completing the
 > current ongoing specification work, on draft and CR specs?
 >
 > Can the web community expect the specifications like XML, XSLT, XQuery
 > and XML Schema to be freezed like HTML and HTTP in near future?
 >
 > It seems to me, the new things that W3C is pursuing these days are
 > mobile web, markup compression etc.
 >
 >
 > --
 > Regards,
 > Mukul Gandhi

[Mukul Gandhi]

On Thu, Oct 29, 2009 at 4:44 AM, T.V Raman <raman@...> wrote:
> Language experience over the centuries  teaches that languages
> once having evolved to perfection die. Said differently, Latin
> and Sanskrit are no longer spoken;-)

I am not sure, how spoken languages relate to programming languages
like XML. Programming languages are used in machine computations,
while spoken languages are not.

> Let's  hope the XML family doesn't end up in  a similar state on
> the Web --- though I fear that circumstances may have already
> caused that to happen.

I am not sure, how XML is competing with HTML or XHTML on the web. I
think, HTML still is a leading technology on a web browser. I wish
though, that people use XHTML on the browser, as it's a HTML dialect
and is well-formed (so XHTML is like XML on a web browser). It seems,
web browsers do not comply widely to latest XHTML standards, as they
do for HTML and XML. I do not know, why browser vendors choose to do
this?

Allowing me to write web pages in XHTML, makes it possible to process
XHTML by XML tools (I can transform it with XSLT, process it via
DOM/SAX or whatever).


--
Regards,
Mukul Gandhi

[T.V Raman]

Humans write programs, machines consume them. Let's hope we dont
evolve into a world where things work the other way around.

Mukul Gandhi writes:
 > On Thu, Oct 29, 2009 at 4:44 AM, T.V Raman <raman@...> wrote:
 > > Language experience over the centuries �� teaches that languages
 > > once having evolved to perfection die. Said differently, Latin
 > > and Sanskrit are no longer spoken;-)
 >
 > I am not sure, how spoken languages relate to programming languages
 > like XML. Programming languages are used in machine computations,
 > while spoken languages are not.
 >
 > > Let's �� hope the XML family doesn't end up in �� a similar state on
 > > the Web --- though I fear that circumstances may have already
 > > caused that to happen.
 >
 > I am not sure, how XML is competing with HTML or XHTML on the web. I
 > think, HTML still is a leading technology on a web browser. I wish
 > though, that people use XHTML on the browser, as it's a HTML dialect
 > and is well-formed (so XHTML is like XML on a web browser). It seems,
 > web browsers do not comply widely to latest XHTML standards, as they
 > do for HTML and XML. I do not know, why browser vendors choose to do
 > this?
 >
 > Allowing me to write web pages in XHTML, makes it possible to process
 > XHTML by XML tools (I can transform it with XSLT, process it via
 > DOM/SAX or whatever).
 >
 >
 > --
 > Regards,
 > Mukul Gandhi