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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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


> -----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
> 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"
> Then, after
> you have done this twenty times, you find you need to move the
> 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,
> 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]