OASIS Darwin Information Typing Architecture (DITA) TC

Groups - Action Item Closed: #0021 Need to update use cases in feat...

  • 1.  Groups - Action Item Closed: #0021 Need to update use cases in feat...

    Posted 10-18-2005 15:21
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    dita message

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


    Subject: Groups - Action Item Closed: #0021 Need to update use cases in feat...


    
    OASIS Darwin Information Typing Architecture (DITA) TC member,
    
    Seraphim Larsen has closed this action item.
    
    Number: #0021
    Description: Need to update use cases in feat...
    Owner: Michael Priestley
    Status: Closed
    Due: 13 Sep 2005
    
    Comments:
    Seraphim Larsen  2005-08-30 17:34 GMT
    From 8/23 minutes --
    
    Discussion: Item 12 -- Universality of universal apps.
    http://www.oasis-open.org/apps/org/workgroup/dita/download.php/13735/IssueNumber12.html
    
    Robert Anderson -- There is some opposition to adding id and
    conref to metadata elements. 
    
    Don -- RA and MP need to have that conversation before
    continuing. 
    
    MP -- We were conservative when we first added these. Were
    currently feature-creeping back to universal. Im now
    suprised to see elements that _dont_ support these. We
    should change the onus from justify having these, to
    justify not having these. 
    
    I can imagine cases where somebody might have different sets
    of keywords, different sets of copyright data. There might
    be a concrete requirement on keyword conrefing for
    controlled vocabularies. Same capabilities you have in
    content but applies to metadata. 
    
    PP -- There are two different issues. conref and filtering
    attrs are quite different. Issue with filtering attrs is
    that semantics. When you think of metadata elements not as
    publishing attrs but searching in CMS. How would a CMS index
    an audience elemetn with audience attribute? Does it
    filter based on who is making the search? If we state that
    these attrs only apply to publishing process, that would be
    clear. If we dont make a statement, CMS vendors will
    implement this in different ways or conspire to ignore the
    attr. 
    
    MP -- Im not sure I buy the premise that CMS is the basic
    use case. 
    
    PP -- Search in general, not CMS. 
    
    MP -- Will these attrs be used for searching source, or at
    publish time? 
    
    MP -- May not be a clean line. May be a muddy line. e.g.
    product metadata. If youre shipping info for a particular
    product, the product metadata is useless. On the other
    hand, if youre publishing to Web site that includes
    multiple products, the metadata is useful again. When
    metadata is useful depends on how and when youre delivering
    it. All will be useful at authoring time. Some will be
    useful at delivery time. 
    
    PP -- Maybe state that these attrs are always applicable to
    publishing process. When applied to metadata attrs, goal is
    to drive publishing process which will generate searchable
    metadata. Have seen customers want to use in other parts of
    the process (internal use). 
    
    MP -- Theres a clear use case for keywords element in
    prolog. Used for search and indexing. 
    
    Robert -- audience attr does have audience attr. 
    
    PP -- Cust asks what it means? If youre using metadata on
    output instead of source and want it to vary based on the
    publishing process, that attr might be meaningful. 
    
    MP -- might have audience element that provides complete
    description of user type. Also slap audience attr on the
    elemnt. When pub for different audience, you can filter out
    that audience definition from prologue. 
    
    Robert -- We need to define what these means when not used
    in publishing context. Also, implementation issue w/conref
    in metadata attr values. Seemed optimistic to me that CMS ]
    will apply conref before they extract metadata attrs. May
    introduce divergence between what the spec allows and what
    is practiced in field. 
    
    MP -- scenario -- controlled set of conref defns, conrefed.
    If CMS is not part of picture, this is very reasonable. If
    CMS is part of picture, may express it as embedded data. 
    
    MP -- It seems like such a clear requirement to manage
    metadata sets. Even if CMS does something different but DITA
    compatible, Id still want to be able use conref to manage
    them. I shouldnt need to pay for a CMS to get centrally
    managed product definitions, for example. 
    
    Don -- Can we put this on the 1.1 plate? 
    
    Robert -- TC needs to be familiar with use cases before
    putting on 1.1. plate. 
    
    MP -- Need to update use cases in feature discussion.
    (Action item)
    
    Tabled until next week.
    
    View Details:
    http://www.oasis-open.org/apps/org/workgroup/dita/members/action_item.php?action_item_id=1012
    
    Referenced Items
    Date            Name                             Type
    ----            ----                             ----
    2005-08-30      minutes.8.23.05.txt              Reference Document
    
    
    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
    


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