agtk-devel

[agtk-devel] Tags internal to Feature

[Sean H. <she...@ug...>]

Hello all,

I apologize if this has been addressed before, but I can't access the archives to find 
out.

I was wondering how one might address tags that are internal to the Feature 
element.  For example, if one had the following in an AG:

<Feature name="content">This is some linguistic data.</Feature>

And one wished for the content to be tagged with features such as stress, like the 
following:

<Feature name="content">This is some <stress>linguistic</stress> data.</Feature>

Such tags might be useful in other contexts, such as transforming data to a readable 
format for presentation, or in transformations to pick out such features.  It is my 
understanding that <Feature> cannot include other elements.

Just curious,

Sean Hendricks

Re: [agtk-devel] Tags internal to Feature

[Steven B. <sb...@cs...>]

Hi Sean,

On Thu, 2003-06-05 at 01:15, Sean Hendricks wrote:
> Hello all,
> 
> I apologize if this has been addressed before, but I can't access the archives to find 
> out.

Sorry about that - to access the list archives you needed to be logged
in to sourceforge.  I've now made the list public so that signing in is
no longer required.  (But posts are still only permitted from list
members).

> I was wondering how one might address tags that are internal to the Feature 
> element.  For example, if one had the following in an AG:
> 
> <Feature name="content">This is some linguistic data.</Feature>
> 
> And one wished for the content to be tagged with features such as stress, like the 
> following:
> 
> <Feature name="content">This is some <stress>linguistic</stress> data.</Feature>

Within AGLIB the value of a feature is an uninterpreted string.  In the
XML DTD, the content of a feature is PCDATA.  So it is fine on both
counts to include well-formed XML markup.

There's one caveat though - I'm not sure what assumptions the file I/O
module makes about the content of features.  (Haejoong would you please
let us know if you see any problem with this?)

-Steven Bird

Re: [agtk-devel] Tags internal to Feature

[Haejoong L. <hae...@un...>]

Steven Bird wrote:

>Hi Sean,
>
>On Thu, 2003-06-05 at 01:15, Sean Hendricks wrote:
>  
>
>>Hello all,
>>
>>I apologize if this has been addressed before, but I can't access the archives to find 
>>out.
>>    
>>
>
>Sorry about that - to access the list archives you needed to be logged
>in to sourceforge.  I've now made the list public so that signing in is
>no longer required.  (But posts are still only permitted from list
>members).
>
>  
>
>>I was wondering how one might address tags that are internal to the Feature 
>>element.  For example, if one had the following in an AG:
>>
>><Feature name="content">This is some linguistic data.</Feature>
>>
>>And one wished for the content to be tagged with features such as stress, like the 
>>following:
>>
>><Feature name="content">This is some <stress>linguistic</stress> data.</Feature>
>>    
>>
>
>Within AGLIB the value of a feature is an uninterpreted string.  In the
>XML DTD, the content of a feature is PCDATA.  So it is fine on both
>counts to include well-formed XML markup.
>
>There's one caveat though - I'm not sure what assumptions the file I/O
>module makes about the content of features.  (Haejoong would you please
>let us know if you see any problem with this?)
>  
>
The '<' and '>' and other characters that are reserved for XML should be escaped, I think. So '<' should be '&lt;' and '>' should be '&gt;', etc.  Otherwise the string will be processed by the XML parser and the original content won't be preserved.

An alternative is to use CAG format, which is not XML. Any string (feature value and metadata value) will be preserved in this format.  No escaping needed.

-Haejoong

Re: [agtk-devel] Tags internal to Feature

[Sean H. <she...@ug...>]

On 5 Jun 2003 at 14:20, Steven Bird wrote:

> Within AGLIB the value of a feature is an uninterpreted string.  In the
> XML DTD, the content of a feature is PCDATA.  So it is fine on both
> counts to include well-formed XML markup.
> 
> There's one caveat though - I'm not sure what assumptions the file I/O
> module makes about the content of features.  (Haejoong would you please
> let us know if you see any problem with this?)

I tried putting in some markup within the content of a feature tag, 
and the markup is stripped out before being loaded into TableTrans.  
Then, when I save it to another AG XML file, the tags are no longer 
there.

Is there a good place within the code that I could look into to see 
why this might be?

Sean

Re: [agtk-devel] Tags internal to Feature

[Steven B. <sb...@cs...>]

On Fri, 2003-06-06 at 00:04, Sean Hendricks wrote:

> I tried putting in some markup within the content of a feature tag, 
> and the markup is stripped out before being loaded into TableTrans.  
> Then, when I save it to another AG XML file, the tags are no longer 
> there.

Haejoong's solution (use < and >) is fine so long as the load
process converts them to their readable versions for display, and the
save function stores them again as entities.  To test this, add a ">" to
a cell in TableTrans, save it to XML, then load it again and see if the
">" is still there.

-Steven Bird

Re: [agtk-devel] Tags internal to Feature

[Sean H. <she...@ug...>]

Just tried it, and it seems to work fine.  All I have to do is write the 
scripts to transform the entities into brackets, and vice versa.  
Shouldn't be a big deal.  Thanks for the input.

Sean

On 6 Jun 2003 at 6:50, Steven Bird wrote:

> On Fri, 2003-06-06 at 00:04, Sean Hendricks wrote:
> 
> > I tried putting in some markup within the content of a feature tag, 
> > and the markup is stripped out before being loaded into TableTrans.  
> > Then, when I save it to another AG XML file, the tags are no longer 
> > there.
> 
> Haejoong's solution (use < and >) is fine so long as the load
> process converts them to their readable versions for display, and the
> save function stores them again as entities.  To test this, add a ">" to
> a cell in TableTrans, save it to XML, then load it again and see if the
> ">" is still there.
> 
> -Steven Bird
> 
> 
>