W3C home > Mailing lists > Public > public-i18n-its@w3.org > April to June 2006

RE: Linking

From: Yves Savourel <yves@opentag.com>
Date: Fri, 7 Apr 2006 07:01:06 -0600
To: "'Lieske, Christian'" <christian.lieske@sap.com>, "'Felix Sasaki'" <fsasaki@w3.org>
Cc: <public-i18n-its@w3.org>
Message-ID: <001301c65a43$55bb1330$0300a8c0@Breizh>

Hi all,

>> But so far I have assumed you could also link to files that have
>> <rules> but are not necessarily only that. 
> From my understanding, the "href" in "rules" should only point 
> to "rules". "locInfoPointer" may point to other stuff.

locInfoPointer value is a relative XPath expression no?
It's not pointing outside the host document is it?
You probably mean locInfoRef.
My understanding was that xlink:href was pointing to a document where there is <rules>.
If we want it to point directly to the <rules> node then wouldn't we need to have an ID for the pointed <rules>? (and do
xlink:href="myRules.xml#myElement", I think).

I guess one of the things we have to decide soon is: Do we allow more than one <rules> per document?
A 'no' answer to that question would probably simplify a few things.

One last note on href pointing to <rules>: The main reason why I find it possibly limitative is allowance for extensibility. One
could easily imagine users who want to use ITS with their own extensions. One way to do that is to insert another namespace in
<its:rules>, but a more flexible way is to create your own format that includes a spot for <its:rules>. This allows to make use of
ITS schema without changing it at all and have validatable document. Something like:

<myXMLI18NDoc ...>
 <its:rules ...>

This scenario may be quite attractive to tools vendors for example.
If href must point to a document that has <its:rules> as its root element this would somewhat limits the way users can take
advantage of ITS.

Received on Friday, 7 April 2006 13:28:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:04:09 UTC