Re: [whatwg] +/- in SGML DOCTYPE
[83.1] N/A because W3C is not an IDN. Dnia 16-12-2007, N o godzinie 00:49 +0100, Terje Bless pisze: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Geoffrey Sneddon) wrote: ISO 8879:1989 states that SGML public text owner identifier registration (i.e., those that start with a + instead of the unregistered -) is defined in ISO 9070, which I don't have a copy of. I can, however, quote the summary from ISO 8879:1989: These [registered owner identifiers] include standards body identifiers for national or industry standards organisations (similar to the ISO owner identifier), and unique codes that may have been assigned to organisations by other standards. Annex K (“Web SGML Adaptations”) to ISO 8879 TC2: [[[ K.4.6 Internet domain names in public identifiers [80] owner identifier = ISO owner identifier | registered owner identifier | unregistered owner identifier | internet domain name owner identifier [83.1] internet domain name owner identifier = +//IDN , minimum data where the minimum data must begin with an Internet domain name.
Re: [whatwg] +/- in SGML DOCTYPE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: [83.1] N/A because W3C is not an IDN. No, but “w3.org” is; and the point was to illustrate that whether the Owner Identifier used is registered or unregistered has nothing to do with whether the source is an officially recognized standards organization or not. Anyone who controls an Internet Domain Name get to issue Formal Public Identifiers with a “+” in them. Granted the IDN option was added to SGML only as of the WebSGML Adaptations Annex, but that's simply because the web made ISO's typical practice of acting as a registry for namespace hierarchy (cf. SNMP OIDs etc.) un-scaleable for the use the web put FPIs to. - -- “See... *That* is the problem... Scotch is for sipping, relaxing, and deep thoughts... Jack is what you drink when you need to work through the pain.” -- John C. Welch -BEGIN PGP SIGNATURE- Version: PGP SDK 3.9 wj8DBQFHZj8io/I+siR19ewRAkB2AKD7HyT0+YHqX9478CVTA1piSHSdAACfeMKZ uJIx4Y2jElJMkGjprOC0+XY�pc -END PGP SIGNATURE-
Re: [whatwg] HTML5 and URI Templates
Maciej Stachowiak wrote: Oh well. Are you really believing this? RFC2396 and RFC3986 define what a URI is. They do not and don't need to say anything about things which aren't URIs. It's been well known for some time that the URI and IRI RFCs do not correctly or sufficiently describe the way user agents must process URIs for compatibility with the Web. This is a bug in the RFCs. For the record: I totally disagree. It's not the job of the URI and IRI RFCs to describe how a user agent has to handle things that do not conform to the RFC3986/3987 syntax. On the other hand, if there's a problem with syntactically correct URIs/IRIs, please be more specific. BR, Julian
Re: [whatwg] HTML5 and URI Templates
On Mon, 17 Dec 2007 12:16:17 +0100, Julian Reschke [EMAIL PROTECTED] wrote: For the record: I totally disagree. It's not the job of the URI and IRI RFCs to describe how a user agent has to handle things that do not conform to the RFC3986/3987 syntax. Why not? The HTML4 WG had this position about HTML as well. This position is what makes interoperability suffer, browser vendors having to spend lots of resources reverse engineering each other, and the resulting de facto error handling being suboptimal (hard to make extensions, for instance). -- Simon Pieters
Re: [whatwg] HTML5 and URI Templates
Dnia 15-12-2007, So o godzinie 19:28 -0800, James M Snell pisze:
form template=http://example.org{-prefix|/|foo}?bar={bar}
method=POST
Foo: input name=foo type=input
Bar: input name=bar type=input
/form
Why is this prefix operator needed here?
What is wrong with the URL http://example.org/?bar=input?
Chris
Re: [whatwg] HTML5 and URI Templates
It's just an example.
Here's another:
form template=http://www.google.com/search?{-join||q,num}
method=GET
input name=q type=text /
input name=num type=range step=1 min=5 max=100 value=5 /
/form
- James
Krzysztof Żelechowski wrote:
Dnia 15-12-2007, So o godzinie 19:28 -0800, James M Snell pisze:
form template=http://example.org{-prefix|/|foo}?bar={bar}
method=POST
Foo: input name=foo type=input
Bar: input name=bar type=input
/form
Why is this prefix operator needed here?
What is wrong with the URL http://example.org/?bar=input?
Chris
Re: [whatwg] HTML5 and URI Templates
If a legacy browser comes across form template=... /, it would be no
different than if it came across a form element with no action
attribute; which means it would have the same impact as the html5 choice
to allow the accept attribute.
It should be possible for us to also do something like:
form action=http://example.org/form_processor;
template=http://example.org?{-join||a,b}
method=POST
input name=a type=text /
input name=b type=text /
input name=c type=text /
input name=d type=text /
/form
In a template-aware HTML5 processor, when the form is submitted, the
value of the action attribute would be overridden by the expanded URI
Template. In legacy browsers, however, the form will be posted to
http://example.org/form_processor. This would provide application
developers with a simple and hopefully transparent fallback for
down-level browsers.
HTML5 Post:
POST /example.org?a=wb=x
Host: example.org
...
c=yd=z
HTML4 Post:
POST /form_processor
Host: example.org
...
a=wb=xc=yd=z
- James
Henri Sivonen wrote:
On Dec 16, 2007, at 05:28, James M Snell wrote:
The gist of the idea (which I believe may have been brought up before
but I'm not certain) is to allow the use of a URI Template in place of
the form element action attribute, and to use form elements to provide
the replacement values, e.g.
form template=http://example.org{-prefix|/|foo}?bar={bar}
method=POST
Foo: input name=foo type=input
Bar: input name=bar type=input
/form
What's the backward-compatibility story of this feature? (Both behavior
of URI templates in legacy browsers and ensuring that existing content
doesn't use braces.)
Re: [whatwg] HTML5 and URI Templates
On Mon, 17 Dec 2007, Julian Reschke wrote: The HTML4 WG had this position about HTML as well. This position is what makes interoperability suffer, browser vendors having to spend lots of resources reverse engineering each other, and the resulting de facto error handling being suboptimal (hard to make extensions, for instance). Because URIs are just a syntactical construct. If there are common requirements for *user agents* how to handle things that aren't URIs but should have been, specify them for these user agents. For instance, why should RDF or XMLNS care about what *browsers* do with broken identifiers? That's pretty much the attitude that led to HTML5 needing to redefine as much as it does. But I guess we can always add URI processing to HTML5 as well while we're at it. If people want to send feedback on what they would have liked the URI spec to say, I can put it into the HTML5 spec in due course. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 and URI Templates
On 17/12/2007, James M Snell [EMAIL PROTECTED] wrote:
It should be possible for us to also do something like:
form action=http://example.org/form_processor;
template=http://example.org?{-join||a,b}
method=POST
input name=a type=text /
input name=b type=text /
input name=c type=text /
input name=d type=text /
/form
[...]
HTML5 Post:
POST /example.org?a=wb=x
Host: example.org
...
c=yd=z
HTML4 Post:
POST /form_processor
Host: example.org
...
a=wb=xc=yd=z
- James
Presumably people will use more than one templated form on their site,
but won't want lots of separate form_processors, so they would have to
use
form action=http://example.org/form_processor?{-join||a,b}
template=http://example.org?{-join||a,b}
method=POST
or something theoretically more correct like
form action=http://example.org/form_processor?%7B-join%7Camp;%7Ca,b%7D;
template=http://example.org?{-join|amp;|a,b}
method=POST
and then they can drop in a standard generic form_processor script to
handle everything automatically.
Most legacy browser users could be handled by a script which adds
onsubmit hooks to rewrite the 'action' attribute before submitting. (I
assume that'd work correctly in current browsers, but haven't tested
it). That would avoid the need for repeating the template URI twice
(with the associated risks of typing one of them wrong and not
noticing), if you don't want to handle scriptless users.
(How would the script know when it should do the rewriting, and when
it should leave everything to the browser? There's no obvious feature
test it can perform.)
Wondering about why this feature would be used:
If everyone who uses template URIs uses these backward-compatibility
additions (which they have to, unless they have no users), why would a
browser implement native support for template URIs? (The reason I can
think of is that it provides a slightly better user experience,
because you can go directly to the destination rather than being
delayed by a round-trip to form_processor, but that's no faster than
the scripted approach.)
If everyone who uses template URIs has to use these
backward-compatibility additions, why would they go to that effort
instead of using some server-side redirection logic to perform the
desired processing at the normal non-templated ugly URI? (Maybe it
makes the system cleaner if the server code has a nice URI-based API
and the client code does the mapping onto that, but I have no idea how
much difference it really makes. More significantly, it allows the
direct use of external resources that have sufficiently nice URIs but
don't have an equivalent GET/POST form-accessible API. I haven't seen
any other obvious useful uses yet.)
--
Philip Taylor
[EMAIL PROTECTED]
