[sc34wg3] Almost arbitrary markup in resourceData

[Kal Ahmed]

Comments inline:

On Wed, 2003-11-19 at 16:41, Mason, James David (MXM) wrote:
> See Below.
> 
> Jim Mason
>  
>         Lars Marius:
>         What does make me worried about <baseNameString> is two
>         things:
>         
>           1) our rationale for allowing XML in <resourceData> is that
>         it's
>              equivalent to <resourceRef>, but <baseNameString> really
>         isn't,
>              and topic names have no [locator] property,
>         
>           2) base names are crucial to all kinds of user interfaces,
>         because
>              they provide labels for the topics, and without those you
>         don't
>              really have much of a UI. We can have resources as names
>         for
>              topics (through variants), but having base names as
>         strings
>              ensures that there's always *something* that can be
>         displayed as
>              a mere string.
>         
>              If we allow markup in here that goes out the door. You
>         may have
>              to strip (or, even worse, render) XML markup to be able
>         to label
>              your topics.
>         
>         I'd be interested to hear what people think of this. Should we
>         change our minds and only do this for <resourceData>?
>         
>         
> It was initially baseNameString that I was most interested in
> corrupting. resourceData is of less importance to me. 
>  
> It may be laziness/ignorance on my part, but baseNameString is what I
> choose to display to my users. I see that name (and indeed all names)
> primarily for human consumption. Variants, resourceData, are of less
> interest to me precisely because baseNameString is what drives my UI.
> It's true that I'm working in an environment where I have a lot of
> control, that I never expect to receive or transmit an arbitrary TM,
> so I don't need the fallback of somewhere having a string that's
> guaranteed to be raw text.
>  
> As I've commented elsewhere in this thread, I don't believe in
> arbitrary interchange. I expect there to be an at least implicit DTD
> for all my data. So there's never really "almost arbitrary markup" for
> me, though the markup may come as a surprise to the topic map engine.
>  
> I never believed in name-based merging because, as a linguist, I'm all
> too aware of the variability and fragility of names. 
>  
> Yes, I need to render XML. For me, the primary problem is that there
> are things I need to display that I can't display without additional
> markup. I sometimes need to display more than one paragraph. I need
> subscripts and superscripts. I need (Oh Horror!) the dreaded
> <emphasis> tag. I need things that will require XSLT processing, such
> as generating labels like "Note:" I don't want the topic map engine to
> mess with that stuff, just pass it through to where the user agent can
> do whatever it takes to render the stuff.
>  
> Maybe I'm pushing topic maps too hard, but the projects I have in my
> shop now generally involve creating portals to collections of
> information, and the users want the information displayed in the
> portal to look like the information it's the gateway to. My impression
> is that I'm not alone in this, that Eric, for one, has similar
> requirements.
>  

Jim, couldn't you use variant names for this ? A variant name with a
"display" parameter would have the <resourceData> element for containing
the display name and so (with this proposal) would allow for your
additional markup requirements. 
>         Lars Marius (and Steve N.):
>         | So, if there's markup in a <baseNameString>, and name-based
>         merging is
>         | switched on, on what basis will name matching be done?
>         
>         The equivalence rule for topic name items. We haven't defined
>         it yet in the presence of markup (will be part of the XML
>         representation proposal), but I think we'll have to base it on
>         Canonical XML. (From what I gathered from Dan Connolly, that
>         seems to be what the RDF folks will do, and for the same
>         reason I propose it: lack of alternatives.)
>         

I thought that the original proposal was for allowing XML elements from
other namespaces to appear *only* in resourceData elements - in which
case this issue does not arise.

Cheers,

Kal 
-- 
Kal Ahmed, Techquila
Standards-based Information Management
e: kal@techquila.com
w: www.techquila.com
p: +44 7968 529531