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] Topic Naming Constraint question



* Lars Marius Garshol
|
| They represent two different standards, with different acronyms, and
| yet they share a common base name (the expansion of the acronym).

* Sam Hunting
|
| The acronymns expand to the same string, but that doesn't mean that
| they share the same subject.

We certainly agree on that! :-)

| This is a general problem with all acronyms -- the expansions are
| always (at least implicitly) scoped. In each case, "XML Query
| Language" really means the language in the particular specification
| where the acronym and the expansion both occur.

Not really. That's just where the expansion is specified. When I say
"Simple API for XML" you don't think that I refer to a particular
piece of a document, do you?
 
| So my thought would be to scope both the basenames and the acronyms
| with a PSI for the specification in which the acronym occurred. (No,
| this doesn't prove that the TNC is broken; round up the usual
| suspects...)

I agree that if your previous para were correct (which I don't think
it is), then scoping as you suggest would indeed be the way to do
this.
 
| A more interesting way to do this -- and I don't really know what
| your requirements are -- might be to do create a map spec by spec,
| and then use mergeMap to add a scoping topic to each map/spec. That
| would prevent the merge you don't want.

It would, but it's really the same as using the spec itself to scope
its basenames, isn't it? What would be the subject of those scoping
topics? I can't think of anything other than the spec itself.
 
* Lars Marius Garshol
|
| The question is: what is an appropriate scope to use on these two
| base names to avoid having the topics forcibly merged?
 
* Sam Hunting
|
| I think that TNC forces a lot of issues to come to light at merge
| time,

Do you mean when two topic maps are being merged? Because there is no
merge time. The TNC is an invariant. It operates at all times. There
is no time where the TNC is not active.

| but that doesn't mean that solutions to those issues are found
| within TNC. It might make sense to ask ourselves how to give the
| developer greater control over the merge process.
 
That would mean changing the spec. As it now stands there is nothing
conditional about F.5.2.

| P.S. Chris's suggestion that "XML Query Language" is really trying
| to show a class/instance relationship is also a good one. Perhaps
| the topic map wasn't designed that way, but perhaps it should be.

It might be, but it wouldn't change anything. All the specifications
that have acronym names have the expansion of the acronym as one of
their base names, so even if I added that topic those base names
wouldn't go away from XQL and XML-QL.

--Lars M.


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://us.click.yahoo.com/kWP7PD/pYNCAA/4ihDAA/2n6YlB/TM
---------------------------------------------------------------------_->

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

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




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


Powered by eList eXpress LLC