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

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

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


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



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

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.

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

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

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

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.

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')

Cheers,

Kal



-------------------------- eGroups Sponsor -------------------------~-~>
Create your business web site your way now at Bigstep.com.
It's the fast, easy way to get online, to promote your business,
and to sell your products and services. Try Bigstep.com now.
http://click.egroups.com/1/9183/1/_/337252/_/973620478/
---------------------------------------------------------------------_->

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

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



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


Powered by eList eXpress LLC