OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: Re: [dita] Proposal for Consideration: Default Behavior for List Items



Hi Andrzej,

I don't mean to suggest that HTML is without faults. Just that the example I posed does not strike me as one of them.

The counter example you offer is not one I'm prepared to defend. I agree it's bad form. I regard it as a failure of XML that it cannot assert sequences on mixed content models. IE, I want to disallow the case you describe, while allowing the case I describe.

Given that failure in XML, it seems we have two opposing strategies:
- mine is to support the defensible markup and try to address the indefensible markup in other ways (authoring guidelines, post-processing cleanup, etc.)
- yours is to disallow both the defensible and indefensible markup, since XML validation cannot distinguish between them.

This doesn't mean we are in horrible disagreement about markup rules, but about where best to draw the line in a continuum of practice.

With regards to the last two things you mention (highlighting domain and conreffing nouns):

- the highlighting domain is explicitly *not* part of DITA base precisely so it can be excluded when more valid markup is available. That said, when the more valid markup is *not* available, I do believe it is better semantically to use <b> then to misuse <uicontrol> or some other semantic element. In other words, the highlighting markup tells us nothing, but that's better than telling a lie.
- re conreffing nouns: I thought we had already gone over this. There are times when it is perfectly legitimate to conref nouns. Here are some of them:

        - reuse of UI strings to ensure consistency between documentation and interface (these can be resolved prior to sending to translation)
        - reuse of product names that have explicitly been vetted for such a purpose (this applies to most IBM product names I believe)
        - reuse of indexterm or prolog metadata content
        - simple lists of nouns (not part of a sentence)

I am frustrated that we seem to always be walking the same ground.

Michael Priestley
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25



Andrzej Zydron <azydron@xml-intl.com>

06/10/2008 04:05 PM

To
Michael Priestley/Toronto/IBM@IBMCA
cc
dita@lists.oasis-open.org, "Bruce Nevin (bnevin)" <bnevin@cisco.com>
Subject
Re: [dita] Proposal for Consideration: Default Behavior for List Items





Hi Michael,

Your example failed to highlight the real problem, which is:

<li>Do something.
     <p>One of three things happens:
         <ul><li>A</li>
                 <li>B</li>        
                 <li>B</li>        
         </ul>
       that really screw up segmentation, translation and any sane
       form of linguistic processing.
     </p>
</li>

The problem is that HTML was a VERY BAD IMPLEMENTATION of SGML. It
concentrated on form rather than structure (mixing up both which is, if
not a sin against humanity, then definitely one against common sense ;)
), which is why we needed XML. Basing an XML vocabulary on HTML (which
would not even parse in SGML terms after about version 2.0) was, at best
IMHO a dubious choice.

Rather like <b>, <u>, <i> and translatable attributes this should all be
consigned to the DITA 'deprecated' bin of history (BTW the same should
be true of CONREF for individual nouns or noun phrases), and good
riddance to it all. Anybody who has had to cope with translating such
documents will testify to the difficulties involved therein.

Best Regards,

AZ



Michael Priestley wrote:
>
> A few points:
>
> - This would be a backwards-incompatible change. That is, it would
> render invalid a large proportion of the existing DITA content out
> there. I think we could consider this for 2.0 if the cost of
> converting all back-level content was justified by the benefits (I'm
> not currently convinced myself, but that would be the timeline to make
> the arguments)
> - This would also render the current task specialization invalid,
> since it specializes a <ph> element as the first child of <step>. As
> an exercise, see what any of the list specializations would look like,
> if only block-level elements were allowed (I suspect it would break
> most of them).
>
> Finally, and leaving aside the pragmatic reasons not to make a
> backwards-incompatible change to the schemas and DTDs at this point,
> I'm still not sure why this:
>
> <li><p>Do something</p>
>        <p>One of three things happens:</p>
>        <ul><li><p>A</p></li>
>                <li><p>B</p></li>        
>                <li><p>B</p></li>        
>        </ul>
> </li>
>
> Is better than this:
>
> <li>Do something.
>       <p>One of three things happens:
>           <ul><li>A</li>
>                   <li>B</li>        
>                   <li>B</li>        
>           </ul>
>       </p>
> </li>
>
> If it's a relic of HTML, I'm not sure why it's a bad relic. The
> adoption of HTML hasn't exactly been crippled by this approach.        
>
> Michael Priestley
> Lead IBM DITA Architect
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25
>
>
> *"Bruce Nevin (bnevin)" <bnevin@cisco.com>*
>
> 06/10/2008 12:22 PM
>
>                  
> To
>                  <dita@lists.oasis-open.org>
> cc
>                  "Bruce Nevin (bnevin)" <bnevin@cisco.com>
> Subject
>                  RE: [dita] Proposal for Consideration: Default Behavior for List Items
>
>
>
>                  
>
>
>
>
>
> [Not sure if this is the right way to contribute to this thread, but I
> don't see any contributor hooks on the page or in the Help. Responding
> to _http://lists.oasis-open.org/archives/dita/200804/msg00060.html_.]
>  
> I agree that rendering is an OT issue.
>  
> The real issue IMO is that <li> permits #PCDATA and phrase-level
> elements. These should only be permitted in paragraph-level elements,
> and any element that permits paragraph-level or "larger" elements as
> children should not permit #PCDATA and phrase-level elements. This
> behavior seems to be a relic of the HTML standard.
>  
> It is easy for OT and vendors to insert <p> by default, and if <li>
> begins with some other child element it is only a minor nuisance to
> delete <p> or insert that child ahead of <p>.
>  
> This would simplify the work of rendering and remove the ambivalence
> that is the topic of this thread.
>  
> Perhaps this is already being considered for 1.3 or 2.0.
>  
>     /Bruce Nevin

--
email - azydron@xml-intl.com
smail - c/o Mr. A.Zydron
                PO Box 2167
       Gerrards Cross
       Bucks SL9 8XF
                United Kingdom
Mobile +(44) 7966 477 181
FAX    +(44) 1753 480 465
www - http://www.xml-intl.com

This message contains confidential information and is intended only for
the individual named.  If you are not the named addressee you may not
disseminate, distribute or copy this e-mail.  Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses.  The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.  If verification
is required please request a hard-copy version. Unless explicitly stated
otherwise this message is provided for informational purposes only and
should not be construed as a solicitation or offer.


[attachment "azydron.vcf" deleted by Michael Priestley/Toronto/IBM] ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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