[dita] Fw: [dita-comment] #12013 Referencing a range of elements

["Yas Etessam" <yas.etessam@justsystems.com>]

Hello Deborah, 

Thank you for your comments, please see responses below.  

Yas


> -----Original Message-----
> From: Rodolfo M. Raya [mailto:rmraya@heartsome.net]
> Sent: Tuesday, August 07, 2007 12:24 AM
> To: dita@lists.oasis-open.org
> Cc: deborah_pickett@moldflow.com
> Subject: [dita] Fw: [dita-comment] #12013 Referencing a range of
> elements
> 
> 
> Forwarding on behalf of Deborah.
> 
> ================================================
> 
> Date: Tue, 07 Aug 2007 11:33:15 +1000
> From: Deborah Pickett <debbiep-ditatc@futzle.com>
> To: dita-comment@lists.oasis-open.org
> Cc: deborah_pickett@moldflow.com
> Subject: [dita-comment] #12013 Referencing a range of elements
> 
> 
> Hi all,
> 
> I'm sick at home and so can't send email from my TC-registered
address.
>  But I wanted to get my comments on #12013 (Referencing a range of
> elements) out there before the next TC call.  Can someone who isn't
> asleep at the time please adopt these?
> 
> The proposal doesn't speak of what happens when filtering removes one
> or
> both ends of the range.  Is this invalid?  Or is it valid, with the
> intervening unfiltered elements remaining?  Is it still valid if all
> elements are filtered out?
>


According to this diagram that shows the DOT's pre-processing
architecture,
http://dita-ot.sourceforge.net/SourceForgeFiles/doc/DITA-preprocessarch.
html, filtering will happen before conrefs are resolved.

If the start/end markers are filtered out, there is nothing to pull in.

The situation would be the same if a pair of matched start/end markers
are orphaned because of filtering.  There is no way to pull in the
intervening (unfiltered elements) if a start or end markers is been
filtered out.  

 
> The proposal doesn't speak of what happens when the range contains
text
> nodes (because the parent element's content model is mixed).  Valid?
> (Perhaps some of the mentions of "element" in the proposal should be
> "node".)
> 

After conferring with Rob Anderson offline, bringing in nodes as part of
the intermediary range is fine. 

I'll  change the wording from 

OLD: Processors will resolve the range by pulling in the start target
and following sibling elements across to and including the end target.

NEW: Processors will resolve the range by pulling in the start target
element, following nodes across to and including the end target element.


  
> What happens when conrefs are chained?  That is, one or both of the
> start/end conrefs is to an element that itself is a regular conref
> and/or a range conref.  Also, the converse, where a regular conref
> pulls
> an element that happens to be one of a start/end pair?  Does it pull
in
> the sibling too, and hence the entire range?
> 

If a start conref is pointing to another element that is conrefd, the
start/end range will need to be resolved first.  Then the rest of the
nested conrefs should be resolved.   This source-first recursion is
discussed in the architectural spec that defines conref processing
behavior.  

http://docs.oasis-open.org/dita/v1.1/CS01/archspec/conref.html

To conref a range to a range, you should have a start and end conrefs
pointing to start and end conrefs.   

If you have a regular conref and it points to an element that has a
start conref, the user's intention is probably to pull in that single
element not the range. 


> What happens when one of the intervening pulled elements is invalid in
> the source content model (because of specialization, say)?
>

At this point, the Open Toolkit checks the element names to make sure
that they match.

Right now, it seems that I was able to possible to pull in and publish
invalid content by creating a note element with a conref to another
note.  In the target note, the note XML contained some invalid content. 

It depends on the processing stream and I defer to Rob Anderson on this
point, but there currently isn't full DTD validation when a conref is
currently brought in.  

 
> I worry about the onus that the author of the reusable content has in
> marking the start/end elements *and not messing with them later*.
That
> presents a level of coupling that standard conref doesn't have.  In
> particular, the common use case of "pull all of the steps in a task,
> then add some of my own" has more overhead than it should.  (Think of
a
> task with only one step (and so only one id on the step).  Others pull
> this singleton step with a range conref, with start/end ids the same.
> I
> then add a second step, and give it a new id.  But all the range
> conrefs
> pulling my steps don't know about this, because they only know of the
> one id, of my original step.)  I know that generic XPath is off the
> radar (good), but there might be some acceptable middle ground
> (something like conref="mytask.xml#taskid/stepsid/*") for common cases
> like this.
> 
> And now the big one . . . I need to be convinced that the
> two-adjacent-element conreftype=start/end markup is better than the
> alternative one-element-with-two-conref-attributes markup.  It seems
to
> me that many of the error conditions mentioned in the proposal would
be
> impossible if there were only one element doing the conref.  It seems
> that the only reason to have two separate elements is so that they can
> have different names, to enable pulling of heterogeneous content.  How
> common is that use case?  Is it worth complicating the architecture to
> accommodate?
> 
>

The current design allows for users who may want to transclude their
content into their XML documents.  Fancier editors will render the
transclusions but for users who are authoring content in tools like
Notepad, this ability to preview the conref range via inclusion is a
usability feature.

As the conref feature is already implemented in many tools and CMS
systems, the addition of a single modifier to enable this form of
short-hand conref is a simpler change.