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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]