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

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution-comment message

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


Subject: Re: rewrite entries processed in document order


Norman Walsh wrote:
> | >
> | > In general, the concept of almost all entries is first match.
> | > Only in the case of delegate--where exact matches don't (usually)
> | > exist--is the concept of longest introduced.
> |
> | Right, but exact matches (usually) won't exist for rewrite entries
either.
> | So if the concept of longest match is appropriate for delegate entries,
> | shouldn't the same concept apply to rewrite entries?
>
> I don't think it's the partial matching that motivates the
> longest-first behavior in delegate; it's the fact that multiple
> delegated catalogs may apply.
> I see longest-first as a mechanism for
> prioritizing the search order on this delegated list. Since rewrite
> rules can have at most one match, I'm not naturally inclined to think
> in terms of priority.
>
> Do you have use-cases in mind that can only be satisfied by
> longest-first rewrite rules?
>

Norm,

This comment was motivated more from a desire for consistency than anything
else.  Even after reading your comment above, I just can't see the logical
difference between wanting delegate entries to match longest first, but not
rewrite entries.

[Tenuous] Use Case:
A site maintains a local copy (mirror) of another.  The mirror site copies
the directory structure of the other, except that one directory is renamed
to avoid a local collision.  This can be implemented using two rewrite
entries but, as it stands, the author must ensure that they are coded in the
correct order.  For example, the following catalog would be broken:-

<rewriteSystem systemIdStartString="http://www.master.com/"
rewritePrefix=file:///local/>
<rewriteSystem systemIdStartString="http://www.master.com/dtds/docbook/"
rewritePrefix=file:///local/dtds/docbookx/>

I think a naive catalog author, who has perhaps coded some delegate entries,
would expect this to work.  In a bazaar twist, if she reworked it so that
two delegate catalog entries were created  instead, and each delegated
catalog entry file contained the rewrite entry, it would work as the author
expected.

I have no desire to be picky, it just doesn't seem consistent.

~Rob




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


Powered by eList eXpress LLC