Re: [xtm-wg] ANNOUNCE: Update of XTM Repository (new XTM prototype DTD)

[Murray Altheim <murray.altheim@eng.sun.com>]

[Preface: I may be slightly wrong in some of these answers, but essentially
I'm hoping to describe what I believe we have in xtm07.dtd. The sample
instance xtm07.xml might help a bit, although I don't know if Steve, Michel
and Sam have looked that hard at the sample. Perhaps one of them can chime
in on my weaknesses...]

Kal Ahmed wrote:
> 
> I'm not going to be attending the Dallas meeting (Steve will be the soul
> Ontopian in attendance). So I just want to throw a few comments on the new
> DTD into the ring.
> 
> 1) Wow...this is...**really** different

Yes, and for the first time I really was able to make sense of *everything*.
And I think Michel and Steve have a shared vision (perhaps for the first time?).
Other than <mergeMap> and <xtm> I feel we're pretty solid. I too have reservations
about the multi-topicmap packaging idea that we will all discuss in Dallas.

I think we were able to re-use syntax where appropriate, and added the
necessary differentiation where it was needed.

> 2) baseName
> I like the division of <baseName> and <variantName> - after the initial
> shock, this seems alot clearer than the old ISO:13250 approach. However, the
> purpose of baseName is not clearly described - I am assuming that only
> baseNameString's are subject to the topic naming constraint and that this
> would be described more clearly in the accompanying prose text.
> I think, however that it might be useful to define two new PSIs for
> 'displayable' and 'sortable' to use as <parameter>'s to partition the
> variantNames in some consistent manner.

Perhaps checking the xtm07.xml example instance will help. The variants
are all about machine processing. You will still scope <baseName> in order
to obtain the <baseNameString> you want. See my example differentiating
by language.

> 3) Identity
> Where did it go ? Perhaps I'm missing something in my reading of the spec,
> but it seems that I have no way to declare the subject of a topic. This is a
> major concern

The <instanceOf> child element in <topic> says what the subject of the
topic is: 

   <topic>
     <instanceOf><topicRef xlink:href="#us-railroad"/></instanceOf>
     <baseName>
       <baseNameString>Union Pacific</baseNameString>
     </baseName>
     ...
   </topic>

 could be translated to:

   "this topic's subject is an instance of 'U.S. Railroad'."

> 4) PSIs
> Is the proposal that a PSI be used like this :
> <association>
>         <instanceOf>
>                 <topicRef xlink:href="&xtm-type-instance;"/>
>         </instanceOf>
> </association>

Yes.

> If so, are the entity declarations implicit in a well-formed interchange
> syntax document ?

No. Implicit only in the sense that you must for well-formed documents
use the full URL. You could normalize a valid topic map that used general
entities for well-formed exchange by expanding all such entities. They're
only meant as a shorthand.

Note that the plan we have is to have the URLs used for the PSIs actually
point to IDs in the XTM 1.0 specification, at the point in the spec where
each of these public subjects is described, eg.:

   http://www.topicmaps.org/xtm/1.0/#psi-supertype-subtype

actually points to 

  ...
   <h3> XTM Public Subject Identifier:
     <a id="psi-supertype-subtype" name="psi-supertype-subtype">
       Supertype-Subtype
     </a>
   </h3>
 
in the spec. [NOTE: The 'id'/'name' redundancy is for backward
compatibility with older browsers.]

> 5) Resolving PSIs
> I would like to see a means of resolving PSIs to a <topic> which is the
> subject, in XTM interchange syntax. Doing this could allow automated
> processes to be more intelligent about semantics on interchanged documents.
> However, I am willing to concede that such a 'PSI Registry' could be built
> on the specification as it stands.

For 1.0, KISS and pragmatic operationality (or some other such way of 
expressing that we want this to *actually work*) should reign.
 
> 6) xtm
> There has been alot of correspondence between Peter Jones and myself with
> regards to this. I am still unconvinced that the content model of xtm as it
> stands solves the stated problem of "serving as a packaging wrapper for one
> or more <topicMap> elements." Either:
>         a) xtm should be fixed to solve the stated problem or
>         b) the problem should be restated (i.e. stated in terms of architectural
> forms processing and explain that processing) or
>         c) killed in XTM 1.0 and resurrected in a companion specification (Either
> 'The XTM Architectural Form Specification' or 'The XTM Packaging
> Specification')

I feel as you, Kal. I'm unconvinced, and I'm sure we'll need to discuss
this further in Dallas. This subject isn't closed, and Steve has admitted
as much. (of course, *no* subject is truly closed, but for expediency we
must focus as much as possible on success in the little time we have
remaining).

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/1/_/337252/_/973635250/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com