W3C home > Mailing lists > Public > www-html@w3.org > November 2004

RE: [newsml] Labels

From: Paul Harman <paul.harman@pa.press.net>
Date: Fri, 12 Nov 2004 13:12:10 +0000
Message-ID: <C01BC7CCA95AE349A558F2BD8F97090C0135E504@palex.panews.press.net>
To: "'newsml@yahoogroups.com'" <newsml@yahoogroups.com>
Cc: www-html@w3.org

From: Misha Wolf [mailto:misha.wolf@reuters.com]
> I keep coming back to the idea of putting the plain-text version in 
> an attribute, eg:
> <label mode="rich" text="Something or other with no markup">
>     Something or other with markup
> </label>
> This wouldn't add much bloat.
> It is, of course, a total no-no from an I18N PoV as I18N, in the 
> general case, needs markup, eg for direction change, language 
> change, and ruby.  On the other hand, those who don't want markup 
> presumably don't care about these issues :-)

I can only see that being useful if label was allowed to be an empty
element, so those who don't want markup (or non-Roman strings) could just
use the attribute. But the downside of /that/ is that attributes should be
kept for systems use, and element contents for human/display use....

I guess it really depends on one's definition of "plain" };*) Is it a bad
thing to perpetuate the special case for Roman languages, and require
non-Roman languages to use the complex Newslines?

> Re the content approach, our main use of markup is in (1) the 
> headline (by which I mean the headline that is outside the content, 
> not a headline embedded in textual content) and (2) in a newsline 
> that explains why a correction has been issued and what the changes 
> are.  Both of these need to be outside the content.

Regarding 2, I see what you mean: being able to mark up the changes in an
editorial notes field could be very useful. I think that's a generic enough
requirement though to be pushed out of Newslines and into some other
(arguably more appropriate) area, though... ISTR NewsMLv1 having a
"Comments" field precisely for this type of information.

It would be good if markup-for-changes could be handled in a generic way
across all providers: and perhaps the mechanism used could be added
to/allowed within all IPTC standards (thinking especially of NITF).

> There is also the question of the byline: We haven't decided how to 
> handle it, but want to show email and IM addresses.  Both of these 
> should use markup.  Now one way of doing this is to refer from the 
> byline to a Person topic-item (once we have such things), but that 
> reference itself requires markup.

This comes back to something I was thinking about earlier and perhaps failed
to adequately convey. Perhaps the <byline> element could carry an idref,
referring to the Duid (or similar) of a <person> element in the
AdministrativeMetadata...? But that wouldn't work very well for items with
multiple authors... :*(


This E-Mail and any attachment is intended only for the person or entity for
which it is addressed and may contain confidential material. If you are not
the addressee or have received this E-Mail in error, please inform the
sender immediately and delete it from your computer. In addition, if you are
not the addressee or have received this E-Mail in error, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
upon it is prohibited and may be unlawful.
If this E-Mail has been transmitted outside the ordinary course of its
business, the company for which the sender works accepts no liability for
any loss or damage suffered by any person arising from any use of or
reliance on information contained in this E-Mail, and any opinion expressed
in this E-Mail is personal to the sender and may not reflect the opinion of
such company. Although the network operator makes every reasonable effort to
keep its network free from viruses, neither the network operator nor the
sender or the company for which the sender works accepts any responsibility
for computer viruses transmitted through this E-Mail or any attachments; it
is your responsibility to virus scan this E-Mail and any attachments. Any
E-Mail reply to this address may be subject to interception or monitoring
for operational reasons or for lawful business practices.
Received on Friday, 12 November 2004 17:18:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:09 UTC