[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [docbook-tc] resource fragments
fwiw, I note that xinclude uses the two attribute approach: an href attribute that is a URI reference without a fragment identifier and an xpointer attribute that gives just the fragment identifier. paul > -----Original Message----- > From: Bob Stayton [mailto:bobs@sagehill.net] > Sent: Tuesday, 2010 February 16 13:08 > To: DocBook Technical Committee > Subject: [docbook-tc] resource fragments > > I have a question regarding referencing fragments of a resource. It > seems there could > be two ways to include a fragment of a resource in your document: > > 1. Define the resource element as a fragment, as in this example from > Larry's sample: > > <resource xml:id="svn.properties" > fileref="subversion/properties.xml#using.properties"/> > ... > <module resourceref="svn.properties"/> > > Here the resource's fileref includes a fragment identifier, and the > module's > resourcref is a straight IDREF. > > 2. Reference a fragment of a whole resource from a module: > > <resource xml:id="svn.properties" > fileref="subversion/properties.xml"/> > ... > <module resourceref="svn.properties#using.properties"/> > > Here the resource's fileref does not have a fragment identifier, and > the module's > resourceref does. > > > In case 1, the fileref attribute is a URI and # is a true URI fragment > identifier. > > In case 2, the resourceref is not a URI but a IDREF. Adding fragment > identifier syntax > after it would not be a valid IDREF, so its definition would have be > changed to CDATA > to accept such syntax. The interpretation of the syntax would be to > fetch the > resource element by its id and attach the fragment identifier to its > fileref value. > Also, this syntax mixes information from the assembly (the resource's > xml:id) and the > resource (the id in the file named properties.xml). > > Are references like case 2 to be permitted? My first instinct is "no", > but I'm sure > that someone will be asking for it at some point. Consider a resource > that is pretty > large, non-editable, and you want to pull multiple fragments from it. > If we permit > only case 1, for each fragment you want to reference from that large > resource, you > would have to define a new resource element using "filename#id" syntax. > Then, after > you have done this twenty times, you find you need to move the resource > file. Now you > must update twenty resource elements to fix the fileref path. > Allowing case 2 would > avoid that problem. > > Perhaps a different syntax might work better: > > 3. Reference a fragment of a whole resource from a module using > another attribute: > > <resource xml:id="svn.properties" > fileref="subversion/properties.xml"/> > ... > <module resourceref="svn.properties" fragment="using.properties"/> > > This would allow a single resource element to reference the file, keeps > resourceref as > an IDREF, and permits referencing a fragment of a resource. It means > adding another > attribute to module, though. > > Bob Stayton > Sagehill Enterprises > bobs@sagehill.net > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]