[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