RE: [dita] Groups - DITA 1.1 #9 (2): element for properties and embedded data (Issue9.html) modified

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

  
-----Original Message-----
From: Erik Hennum 
  [mailto:]
Sent: Tuesday, September 06, 2005 6:29 
  PM
To: 
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

  http://www.oasis-open.org/apps/org/workgroup/dita/download.php/14073/Issue9.html
and 
  the exchange below

  
    
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.

Apart from that discussion, I'd like to check 
  whether anyone has concerns about

  
    
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).

On the last point, I'd 
  submit that allowing the <data> element in <topicref> contexts 
  dispatches Issue 36 as well (a two-fer):

  http://www.oasis-open.org/apps/org/workgroup/dita/download.php/13537/DITA-TC-1dot1PublicRequirementsWithEffort.html
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/200504/msg00003.html
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




  
    
    

      
        
          
            
               
                
09/06/2005 11:24 AM

      
        
          
          

            

              
To

            


          

            

              
cc

            

          

            

              
Subject

            
[dita] Groups - DITA 1.1 #9 (2): element for properties and 
              embedded data (Issue9.html) modified

        
          
          

            
            

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