Re: architectural processing with nsgmls/jade for queryloc

[Peter Newcomb <peter@xxxxxxxxxx>]

[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