OASIS Darwin Information Typing Architecture (DITA) TC

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

  • 1.  Re: [dita] Groups - DITA 1.1 #9 (2): element for properties and embeddeddata (Issue9.html) modified

    Posted 09-06-2005 22:35
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    dita message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


    Hi, Esteemed DITA Commmittee Members:

    Regarding the <data> element proposal


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

    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


    Inactive hide details for <a href=seraphim.l.larsen@intel.com">seraphim.l.larsen@intel.com



    To

    dita@lists.oasis-open.org

    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

    GIF image



    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]