OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[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