Good issues for probing the design -- I've some responses.
1. User-defined data
Like the existing <state> element, the <data> element provides a name attribute for this purpose. In fact, it's probably a best practice for specializers to provide a default name and offer the users of their specialization the ability to add user-defined precision to their specialization.
<data name="product-family" value="Everything Anyone Could Want">
<data name="product" value="This Most Valuable Product">
<data name="model" value="At Your Price Point">
<data name="configuration" value="With Your Features">
<data name="feature">Feature One</data>
<data name="feature">Feature Two</data>
</data></data></data></data>
<data name="recipe">
<data name="ingredients">
<data name="ingredient">Any starch</data>
<data name="ingredient">Any topping</data>
</data>
<data name="item served">Food consisting of starch with topping</data>
</data>
In the examples, I've moved the parent values into the value attribute because, as Dana pointed out in correspondence, the purpose of the <data> element is to arrange atomic values in structures. Thus, the best practice for specializers and users is to avoid mixed content models.
Of course, as with any pattern that isn't encoded by the markup, the consistency of the instances of the product and recipe data structures depends entirely on the diligence of the writers. Better than nothing, and the patterns could be validated with Schematron (though that would be about as complex as specialization with less benefit).
The outputclass (aka, the poor man's specialization) can also be used for sharing a semantic across multiple instances, but I think you'd want the ability to apply the same outputclass to multiple named values, so it wouldn't specify user-defined types for data.
2. Referring to instances
The <data> element would use the same referencing mechanisms (including the new keyref) as any other DITA element to become the target or source of a refererence:
<topic id="thisTopic">
...
<prolog>
<author id="topicAuthor">Charles Schulz</author>
<data name="profession" abouthref=""#thisTopic/topicAuthor">cartoonist</data>
This example assumes that the universal attributes has provided an id on <author> so the instance can be referenced.
I think the initial scenario (specifying a default author) would be addressed through conref or by specifying the author at the root of a branch in the map.
The example does make me wonder whether metadata elements that take content (like <author>) should add <data> to their content models so extended properties can be nested instead of referential.
3. Rebasing existing properties on <data> in DITA 2.0
Excellent point about extending DITA modularity to the existing topic metadata -- that is, moving the existing topic properties into a pluggable domain. As an additional benefit, that would make those properties easier to share between topic and map.
The hitch for rebasing on the <data> element is the existing attributes of the properties. We'd need extension by addition for attributes or attribute specialization / mutability. But, those are good goals for DITA 2.0 anyway.
4. Filtering based on the <data> element
In XSLT, you could create a filtering rule like the following:
<xsl:template match="*[contains(@class,' topic/topic ')] //
*[contains(@class,' topic/data ') and name='recipe'] /
*[contains(@class,' topic/data ') and name='ingredients'] /
*[contains(@class,' topic/data ') and name='ingredient' and
contains(text(),'starch')]"/>
That would drop any topic with a recipe that uses starch. You'd also need to filter out the references to the topic, but the strategy would be similar.
Thanks for digging into it,
Erik Hennum
ehennum@us.ibm.com
"Esrig, Bruce (Bruce)" <esrig@lucent.com>
09/07/2005 03:26 AM |
|
The <data> proposal as it stands is a mature proposal that meets most of the criteria I was inquiring about in the TC meeting of 30 August. For example, it is specifically designed for providing structured metadata that supports filtering similar to the current conditionalization functionality.
I do have four residual remarks that the proposal seems not to address. Examples are provided after the remarks.
1. Two notions of type are provided, but not a simple user-defined type. The audience appears to be specializers but not end users. This means that organizations that want to use DITA without employing a DITA specializer won't have some of the intended flexibility.
So an end user cannot embed (supposing that this was desired) variables or values from a programming language each preceded by the applicable type unless the type system of that programming language is already anticipated by the specializer. And programming languages with user-defined types make it impossible to anticipate all the possible types.
Since I don't have programming language examples available, I use data-representation examples that have a similar form.
2. Has pattern-matching been considered in full generality? The name attribute could be used to create a name-value binding that could be matched against. However, no syntax is provided for stating a value that incorporates a name defined elsewhere.
3. What are the implications for DITA 2.0? Can we re-map all existing prolog elements and metadata so that they specialize <data> and appear in a more predictable context?
This discussion assumes that we would want a mechanism for introducing metadata that permits but does not require standardization across organizations. The specific metadata in DITA seems to be there because a need was found for that metadata. Rather than trying to establish standard metadata through language definition to permit interchange across organizations, we would externalize that effort. So in the language specification, we might no longer require support for some of the existing metadata. We may choose to provide backward compatibility with a library of supporting modules.
4. How does the <data> element integrate with conditionalization functionality?
---------------
Examples:
1. User-defined types
Product specifications that include more detail or different detail than anticipated
<data user-type="product-family">Everything Anyone Could Want
<data user-type="product">This Most Valuable Product
<data user-type="model">At Your Price Point
<data user-type="configuration">With Your Features
<data user-type="feature">Feature One</data>
<data user-type="feature">Feature Two</data>
</data></data></data></data>
Classification information for user-initiated information sharing
<data user-type="recipe">
<data user-type="ingredients">
<data user-type="ingredient">Any starch</data>
<data user-type="ingredient">Any topping</data>
<data user-type="item served">Food consisting of starch with topping</data>
</data>
2. Pattern matching
Data provided in a map context to provide a binding.
<data name="default-content-author">Charles Schulz</data>
Data provided in a topic context to accept a default value for metadata if no overriding value is provided.
<prolog><author>$default-content-author</author></prolog>
3. Impacts on DITA 2.0
The author element is a specialization of <data> with the constraint name="author", equivalent to
<data name="author">.
All the elements within <metadata> are defined as specializations of <data> with a new attribute metadata that defaults to "yes". Other existing elements of prolog have an attribute metadata that defaults to "no".
4. Conditionalization
(Further detail requesting an example.)
Given the data in item 1, for example, how would you set up a filtering mechanism that takes advantage of the data in order to do conditional processing? Would we use the existing include/exclude filtering architecture?
Best wishes,
Bruce Esrig
- The proposed <data> element can nest to express complex structures as shown in the specialized examples in the proposal.
- Because the property represented by each <data> element has an unambigous subject and object (thanks to Paul Grosso's good efforts), an XSLT rule could perform filtering based on the <data> element even if the match requires multiple levels within the structure. Regardless of the filtering mechanism used, that shouldn't require changes to how the specialized <data> elements express the properties.
- I'd submit that conditional processing doesn't require a special class of properties but rather a special use of properties. For instance, the selection attributes provide properties that, while extremely useful for conditional processing, could also be used for search, display of categorization, or other kinds of processing. Thus, we don't need to distinguish conditional and non-conditional <data> element specializations.
- The typeid attribute for associating a specialized <data> element with a well-known public identifier for the property.
- The contexts in which the data element can appear (roughly equivalent to metadata contexts, content contexts above the keyword level, and map contexts; see the note for details).
- -----Original Message-----
From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Tuesday, September 06, 2005 6:29 PM
To: dita@lists.oasis-open.org
Subject: Re: [dita] Groups - DITA 1.1 #9 (2): element for properties and embedded data (Issue9.html) modified
Hi, Esteemed DITA Commmittee Members:
Regarding the <data> element proposal
and the exchange below
Apart from that discussion, I'd like to check whether anyone has concerns about
On the last point, I'd submit that allowing the <data> element in <topicref> contexts dispatches Issue 36 as well (a two-fer):
Given that no other comments have come in for some time (even allowing for vacations), can we treat this note as a last call for comments before wrapping up and (absent unresolved concerns) proceeding to a vote next week?
Thanks,
Erik Hennum
ehennum@us.ibm.com
seraphim.l.larsen@intel.com
09/06/2005 11:24 AM |
|
This proposal was approved at the 8/30/05 meeting:
- #9 Add a element for representing machine-processable
values within DITA topics and maps
http://www.oasis-open.org/apps/org/workgroup/dita/download.php/14073/Issue9.html
Erik -- This should be designed more fully before the
committee can vote on it.
- is the committee willing to approve completing the design?
- what holes does the committee see in the design?
Erik requests feedback to email list.
Bruce Esrig -- Any relationships with other issues? e.g.
Need to record structured info for other purposes?
Don -- Does this effect design, or just that context of data
element meets those requirements.
Bruce -- e.g. conditionalizatoin attrs. Then possible to
design special structures used for conditionalization. Do we
want to design the data structure to do conditionalization?
Paul Prescod -- How would a user use the intersection of those two
things?
Bruce -- Put value in conditional parameter. Assumed to be a
global unique value. If the person wants to draw those names
from a (product hierarchy), they may need to come up with
some structures. Those structures may be similar to those in
the data element.
PP -- Might this be system-wide metadata?
Bruce -- Problem comes if lower-level names are not unique.
e.g. switch and 17 product names have switch.
Erik -- Existing prodinfo element is example of that.
Bruce -- This may not specifically apply under the data
proposal. Perhaps it should proceed around the profiling
proposal.
Don -- Does this inform on the design of the data element,
or is it a best proactice?
Bruce -- Could inform design if requires nesting (?)
Don -- In general, I think we want to keep the feature of
cond processing separate from the design points of the
elements in dita. Bruce, please correspond w/ Erik re: use
cases on email list (plus any other feedback on design). A
complex, real-world example would be nice to have in the
spec.
PP -- Bruce -- can you send email to list highlighting these
issues?
Approved for 1.1
-- Seraphim Larsen
Information about the document named DITA 1.1 #9 (2): element for
properties and embedded data (Issue9.html) has been modified by Seraphim
Larsen.
Document Description:
HTML output from DITA note
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/dita/document.php?document_id=14073
Download Document:
http://www.oasis-open.org/apps/org/workgroup/dita/download.php/14073/Issue9.html
PLEASE NOTE: If the above links do not work for you, your email application
may be breaking the link into two pieces. You may be able to copy and paste
the entire link address into the address field of your web browser.
-OASIS Open Administration
[attachment "graycol.gif" deleted by Erik Hennum/Oakland/IBM] [attachment "ecblank.gif" deleted by Erik Hennum/Oakland/IBM]
- References:
- RE: [dita] Groups - DITA 1.1 #9 (2): element for properties and embedded data (Issue9.html) modified
- From: "Esrig, Bruce (Bruce)" <esrig@lucent.com>
- RE: [dita] Groups - DITA 1.1 #9 (2): element for properties and embedded data (Issue9.html) modified
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]