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

"Henry S. Thompson" <ht@inf.ed.ac.uk> 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. . .

Ok. I over-estimated the scope of the proposal, I guess.

I'm still opposed to it though. Given a random +xml vocabulary that I
don't know anything about, I want a license to try to resolve the
fragment identifiers using application/xml semantics.

> 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. . .

My XProc processor assumes that it can interpret "foo" in

  <p:document href="someURI#foo"/>

as a 3023bis fragment identifier if the MIME type of "someURI" is
application/anything+xml.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Syllables govern the world.--John Selden
http://nwalsh.com/            |