[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK: Re: [docbook-tc] DocBook Technical Committee Meeting Minutes:19 Nov 2002
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 / Paul Grosso <pgrosso@arbortext.com> was heard to say: | At 14:40 2002 11 19 -0500, Norman Walsh wrote: | |>| 6. Instance-based cross-reference text |> |>This is on the agenda for Paul to consider use cases. Unfortunately, |>Paul isn't here this week. |> |>ACTION: Bob to discuss with Paul for next month. Plan to close next month. | | Oops, what was/am I supposed to do here? Someone remind me what | this is about please. The October minutes[1] say (of instance-based xref text): PG: I'm still interested in making sure that all of the obvious use cases are covered. I think you were supposed to think about it :-) |>| 615587 Support xml:base |> |>Any object to adding xml:base to the common attributes? None. | | Hmm, no discussion? I'd have had lots of questions. Well, badly minuted perhaps. The principle concern is that XInclude support adds xml:base attributes to reflect the location of the included entity. So if you're doing XInclude before DTD validation, the DTD needs to allow xml:base. The xml:base attribute doesn't add any namespace declarations or other problems (because "xml:" is magic) so there didn't seem to be any harm in adding it. | Just what is the point of xml:base? Having xml:base is | only useful if there are relative URIs within scope, so | it's important to answer just what values are supposed to | be affected by xml:base. | | So just what things in DocBook are affected by xml:base? Off the top of my head, url on <ulink> and fileref on graphics are the only places where xml:base will matter. | Does xml:base affect the value of the fileref attribute? | What about ulink's url attribute? They are both just CDATA, | so how is an application supposed to know whether they should | be affected? Yet users will certainly expect them to be. The same way it knows they're URIs, I suppose: application-specific semantics. In some future schema-based world, we can expect those attributes to be of type xs:anyURI, but for the time being, applications will just have to fake it. | What else, if anything, will be affected? Maybe xincludes, | but the next item says we rejected supporting xinclude. We rejected adding xi:include to any content models, that's not rejecting the use of XInclude, only rejecting the notion of validating them in the DTD. Be seeing you, norm [1] http://lists.oasis-open.org/archives/docbook-tc/200210/msg00005.html - -- Norman Walsh <ndw@nwalsh.com> | The first step towards madness is http://www.oasis-open.org/docbook/ | to think oneself wise.--Fernando Chair, DocBook Technical Committee | De Rojas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/> iD8DBQE926oqOyltUcwYWjsRAkQqAJ42EJT5AgX5xAyDv0fYLKbTgjMldgCcC2fU 2JAYfxpj+bQX3Lrj0ShPU5M= =LeeF -----END PGP SIGNATURE-----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC