Subject: Re: architectural processing with nsgmls/jade for queryloc From: Peter Newcomb <peter@xxxxxxxxxx> Date: Thu, 11 Jun 1998 14:02:16 -0500 |
[Gerhard Stenzel <stenzel@xxxxxxxxxx> on Thu, 11 Jun 1998 17:32:57 +0000] >>> Where is my "http://test/cgi?test" gone? I would expect it between >>> the two QUERYLOC lines. Is this expectation wrong? >> >> The queryloc form does not include #PCDATA in its content, and >> therefore the content of your URLLOC element is not considered >> architectural (since the default setting for ArcIgnDA is cArcIgnD). > > I tried > > <!ATTLIST urlloc > id ID #REQUIRED > HyTime NAME #FIXED "queryloc" > notation (URL) #FIXED "URL" > ArcIgnDA nArcIgnD #IMPLIED > > > > and > > <!ATTLIST #NOTATION HyTime > ArcIgnDa CDATA #FIXED nArcIgnD > ... > > Result is the same: missing URL. What am I doing wrong here? First, you need to specify the ArcIgnDA attribute name in an architectural support attribute: <!ATTLIST #NOTATION HyTime ... ArcIgnDA NAME #FIXED HyIgnDat > And then you specifiy a (default) value for the attribute: <!ATTLIST urlloc id ID #REQUIRED HyTime NAME #FIXED "queryloc" notation (URL) #FIXED "URL" HyIgnDat NAME #FIXED nArcIgnD > But this would only result in an error, since the queryloc form does not allow #PCDATA in its content model. >> This is because it is the content of the client (urlloc) element >> that is given to the query notation processor, not the content of >> the architectural (queryloc) element. The queryloc form was >> designed this way to account for the possibility that the query >> itself might not be a simple string, and instead might be expressed >> as a set of elements conforming to a particular query architecture, >> in which case it would almost certainly not work to process only >> the HyTime architectural instance. > > Let me see, if I understand this: > A HyTime engine could work on the HyTime architectural instance of > the document, because there are all the elements it knows, but in > the case of a queryloc it must use the client instance of the > document to get access to the actual query information. > Is this a correct summary? Yes. > If yes, does this meam a HyTime engine always has to work with both > instances? Yup. The HyTime architectural instance basically tells the HyTime engine what it needs to do with (i.e., how to interpret) the client instance. > Or should I better forget the architectural instance and work on the > other one instead from the beginning? I'd say that if you're aiming to create a general purpose tool (although not necessarily a fully-featured tool), you should be looking at both instances. If you need to get something less general done quickly, then you might be better off taking a shortcut and baseing your processing solely on the client instance. Remember, though, that even if you take the shortcut now, using HyTime as you are to describe some of the semantics of your architecture will mean that when more general tools become available, your data will still work. -peter -- Peter Newcomb at TTI: +1 972 231 4098 TechnoTeacher, Inc. at ISOGEN: +1 214 953 0004 x141 http://www.techno.com/ email: peter@xxxxxxxxxx DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: architectural processing with n, Gerhard Stenzel | Thread | Re: architectural processing with n, Gerhard Stenzel |
Re: architectural processing with n, Gerhard Stenzel | Date | Re: architectural processing with n, Gerhard Stenzel |
Month |