W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > June 2010

Re: TAG concern wrt 3023bis, +xml media types and fragids

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Fri, 18 Jun 2010 16:48:12 +0100
To: Norman Walsh <ndw@nwalsh.com>
Cc: public-xml-core-wg@w3.org
Message-ID: <f5b7hlwibpf.fsf@calexico.inf.ed.ac.uk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Norman Walsh writes:

> Partly because 3023bis has taken for f'ing ever, I think there are
> lots of specs out there that have been written with the assumption
> that 3023 will define a common fragment identifier scheme. I can name
> two off the top of my head:
>
>   http://www.w3.org/XML/XProc/docs/langspec.html#fragid
>   http://docs.oasis-open.org/docbook/specs/docbook-5.0-spec-os.html#fragid

I don't see any problem with this.  Both those specs explicitly opt
_in_ to 3023bis's syn/sem for fragids as speced therein for
applicaition/xml.  So they are precisely compatible with Noah's
proposed change, which would amount to _requiring_ such an explicit
opt-in. . .

Still looking for an example of a case where (to now make things
concrete) some 'generic' XML processor which conformed to the proposed
change to 3023bis would do the wrong thing wrt some URI of the form
xxx#yyy, where xxx identified itself as application/xproc+xml, and the
implementors of said processors were _not_ aware of the opt-in.

IOW, what generic XML processor inteprets fragids at all. . .

ht
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFMG5U9kjnJixAXWBoRAnAeAJkBvWJgHAjcT9hyOcs2j0gVN2z7JwCfWBl1
eeREQuoi8w3YC+RG1/ANVgo=
=d3BE
-----END PGP SIGNATURE-----
Received on Friday, 18 June 2010 15:48:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:40:41 UTC