- 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>
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 ...> </its:rules> <mystuff> </myStuff> </myXMLI18NDoc> 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. Cheers, -yves
Received on Friday, 7 April 2006 13:28:02 UTC