Public Comment

[comment-form@oasis-open.org]

Comment from: ehennum@us.ibm.com

Conref and XInclude

Regarding the quest for a moral equivalent (oh treasured phrase!) to XInclude...

Eliot Kimber <ekimber@innodata-isogen.com> wrote on 06/22/2004 10:05:20 AM:
> 
> However, I think there are simple ways to create an 
> authoring-appropriate form of XInclude that would be consistent with the 
> general DITA requirements and the current DITA design while providing a 
> direct path to standard XInclude via a trivial transformation.

Might DITA introduce a pseudo-XInclude namespace so the attributes of the xi:include element could be added (ala XLink) to any DITA element that takes the conref element today?

That is, DITA topic might declare the pseudo-XInclude namespace with an attribute of xmlns:xix that has a fixed value of "urn:oasis:names:tc:dita:xinclude-extended" or some such.

Then, conreffable elements contained by topic could have the xix:href, xix:parse, and other XInclude attributes.

This approach could be submitted for for XInclude 1.1 as a syntactic alternative to the existing xi:include element.  (For one thing, that would let someone add XInclude capability to an existing DTD because content models are difficult to modify while attributes are easy 
to add.)

That said, as noted in the previous posting, the TC might want to continue to support DITA fragment locators as an alternative to XPointers because of the authoring benefits.  If, however, XPath were enhanced with the notion of a scoped ID, that would flow into XInclude attributes as a matter of course.

> 1. Use some sort of typing mechanism to map specialized element types to 
> the base xi:include type. For DITA we could simply re-use the existing 
> DITA typing mechanism and make xi:include a built-in core type....
> 
> The one potential wrinkle here is that in the current DITA design a 
> given element type may be either a content container or a content 
> reference. My personal preference is that referencing element types 
> should always be distinct from the content-containing element types, 
> mostly to make it clearer to authors when they are creating a reference 
> and when they are not. It also avoids the problem of what to do when an 
> element contains both content and makes a use-by-reference. DITA 
> addresses this by imposing the business rule that elements that use 
> conref= must have empty content, but there is no way to express or 
> enforce this rule using normal DTD or schema constraint specifications. 

The type agreement between the referencing element and the referenced element guarantees that editing in either the referencing or referenced
topic can't invalidate the reference so long as the elements themselves remain the same.

If we create distinct referencing and referenced elements, wouldn't we either lose that guarantee or require a referencing element for each 
referenced element, increasing the element count and complexity?

Also, could the ability to have content within a conref element be a virtue?  Editors could populate a conref element with a snapshot 
of the referenced content, refreshing the snapshot during processing in the same way that conrefs are resolved today.

That way, the editor could always display complete content but prevent editing of the snapshots.  In addition, the topic could always be 
processed even if the referenced content wasn't available.

> For requirement 3, either continue to just define the reference 
> constraints in prose or define additional elements or attributes that 
> can explicitly define the reference type constraints. In my designs I 
> use an attribute called "reftype=" that, at a minimum, takes the name of 
> the required target element. It could also take, for example, an XPath 
> expression that defines the allowed referents, possibly in terms of the 
> value of a type-mapping attribute, e.g.:
> 
>   <para conref="yourdoc.xml#/topic2/para-04"
>         reftype="//*[contains(@class, ' para ')]"/>

Can you expand on why the reftype attribute would be useful?  Wouldn't the class attribute of the referencing element provide that information?

> Finally, XIinclude breaks element addresses into two attributes: href= 
> for pointing to entire documents and xpointer= for pointing to 
> individual elements. I think this is a good design and prefer it over a 
> single href=, for all the reasons stated in the XInclude spec.

I looked but didn't find the reasons - can you point to them?

Splitting the file reference and fragment into different attributes does break with HTML and XLink tradition.  To expand, I'm wondering 
whether the processing benefits (avoiding splitting the string at the hash) are less than the authoring drawbacks (complication).
For instance, you wouldn't be able to copy, paste, and edit an address as a single value.

Finally, after DITA 1.0, the TC might want to consider whether to support a conref option to preserve the attributes on the referencing element instead of getting the attributes on the referenced element.  Effectively, the first approach would reference only the content while the second approach (the existing conref) references the container as well as the content.