[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] <include> element in base vocabulary for DITA 2.0
I’ve never considered using <xref> to describe form fields. When talking specifically about forms, I think of the source/destination of an input’s value as metadata on the input, not the primary nature of
the input. For example: <textfield [class=”+ topic/data input-d/input widget-d/textfield “ datatype=”text”] id=”firstName”> <required [class=”+ topic/data input-d/inputConfig widget-d/required ” name=”required” value=”true”]/> <minLength [class=”…” name=”minLength”] value=”3”/> <datapoint [class=”…” name=”datapoint” scope=”external”] keyref=”user/firstName”/> <!-- OR --> <datapoint href=""> </textfield> All of which is to say that I don’t consider the hookup of form fields to their data sources to be quite the same use case as processing-time transclusion. I’d be open to working on any proposals related to adding a ‘forms’ domain to DITA 2.0. I might even consider submitting such a proposal when the time comes. Chris From: <dita@lists.oasis-open.org> on behalf of Don Day <donday@donrday.com> During the discussion of this item in the 19 July 2016 TC meeting, I mentioned some experiences I had with transclusion behaviors. My use case was using DITA to represent a form front end to a database. Normally, we edit DITA documents directly. In this
case, DITA markup represents form fields that get their content from a database--literally a transclusion aspect. I needed to represent a transclusion query, which is different than a conref query, so @conref was out as a way to model the query. I made peace
with xref because @href represents the query semantic, while it still has a conref semantic in the processing role of getting a title as content. Here are a few lines of a "document-as-form": <dl id="xpdformdata" outputclass="asForm" spectitle="Add Event" class="- topic/dl ">
<dlentry class="- topic/dlentry ">
<dt class="- topic/dt ">Event Name:</dt>
<dd class="- topic/dd ">
<xref type="head" href="" format="form" class="- topic/xref "/>
</dd>
</dlentry>
<dlentry class="- topic/dlentry ">
<dt class="- topic/dt ">Event Type:</dt>
<dd class="- topic/dd ">
<xref type="select" href="" format="form" class="- topic/xref ">
<data value="conference" class="- topic/data ">Conference</data>
<data value="webinar" class="- topic/data ">Webinar</data>
<data value="meeting" class="- topic/data ">Meeting</data>
<data value="training" class="- topic/data ">Training Class</data>
<data value="other" class="- topic/data ">Other</data>
</xref>
</dd>
</dlentry>
...
And notes FWIW from my transform file: <!-- use xref to represent an input field in a form: xref type="input" href="" format="form"--> CSS sample: render the queried title LIKE a title And as rendered (with no data in this case, hence "CREATE" role in database): From a webinar slide I gave about this process:
Definition list "specialized" to represent forms
The net is that I was able to make peace with xref as a tranclusion element. I used it to transclude SQL field data, but the semantic justifies pulling in any other non-DITA (or DITA) rendition type as well, as long as the application has a standard way
of recognizing that rendition role and applying it. This is why I mentioned "viewport" as a way of describing what is happening in this case. Hoping this helps the discussion. -- On 6/25/2016 8:51 AM, Chris Nitchie wrote:
-- Don R. Day "Where is the wisdom we have lost in knowledge?
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]