OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XML and XPATH: How do they work?

[ Lists Home | Date Index | Thread Index ]
  • To: Alexander Johannesen <alexander.johannesen@gmail.com>
  • Subject: Re: [xml-dev] XML and XPATH: How do they work?
  • From: Joe Schaffner <schaffner.joe@gmail.com>
  • Date: Mon, 4 Jul 2005 22:00:24 +0300
  • Cc: xml-dev@lists.xml.org
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=khM8uW0VfhsiNlQZRi5UPpLxze5KxYyWw9YjptS63rb8EVTYFJv1RkhWhzT0Su1z/mOaN2jJstcCKLJskNOQIpbsIM43Qy2ocE/er5k32wrMm+oeCYYwAFpjTH/VrbjCoMkuHh6krJyS8XX92wR2qbSAR9oxR0gMSddLnydSx8E=
  • In-reply-to: <f950954e05070123267e92abff@mail.gmail.com>
  • References: <514a17f5050628033555ee4b93@mail.gmail.com> <42c13661.479df431.75d6.4f91SMTPIN_ADDED@mx.gmail.com> <514a17f5050629044523ed06e7@mail.gmail.com> <f950954e05062905034ffea849@mail.gmail.com> <514a17f5050630033015047976@mail.gmail.com> <f950954e05070123267e92abff@mail.gmail.com>
  • Reply-to: Joe Schaffner <schaffner.joe@gmail.com>

Thanks Alex, for your nice reply. I really appreciate it.
 
Can you recommend an XSD validator?
 
I want a simple one, a command line filter, one which works on stdio, the schema as the only argument. I hate rpms, so a small collection of statically-linked, command-line filters is what I want. No Java RTE, s'il vous plait.
 
I'm using SuSE 9.2. Linux.
 
Also, an XSL processor?
 
I'd like the tools to work as simply as possible. I was thinking, applying an XSL stylesheet to an XML document should look something like this:
 
$ xslproc  my.xsl < my.xml > my.html
 
Is there anything out there like this?
 
 
Thanks, you've been great.
 
Joe
 
PS
 
>> In other words, I'd like to keep the formal model as simple as possible: I
>> want as few "types" as possible, maybe only one. Then I merely create named,
>> linked lists which tie all the instances together.

> Like ;
> verb a, verb b, verb c, verb d (they're all just 'verbs')

> and then
> "silly verbs" : verb a, verb d
> "cool verbs" : verb a, verb c
> "funny verbs" : verb b, verb c, verb d

> ?
 
Exactly.
 
Today I was linking all the verbs which express "luck" - τύχη - like: {ατυχώ (I have no luck), ευτυχώ (I have good luck), δυστυχώ (I have bad luck), πετυχαίνω (I succeed)}.
 
Over time, the conjugations have changed, so the verbs belong to different morpological models. Now they're all on the same list, linked on the (English) meaning!

> If so, that is no different to ;

> verb a : isSilly, isCool
> verb b : isFunny
> verb c : isCool, isFunny
> verb d : isSilly, isFunny
 
You're right, the intent is the same, but the verb dictionary is the "data" dictionary too.
 
I don't want to rely on a separate structure built up by a tool from definitions in my schema, even if that tool were capable of creating the hyper-links (A paper version of the dictionary would print the lists in the back as an appendix) - the definiton language gets in the way before long.
 
I want the metadata to remain in the application domain where I see it.
 
And I want to wing it. :)
 
>> A processing program
>> would follow the links on a named list. Any verb belonging to the (semantic)
>> category would be a node in the list. Any node can belong to as many lists
>> as I want. The name of the list would be the name of the category.

> What you're describing is just objects with properties, and you have
no semantics betwen your verbs at all (apart from them being typed).
Is that what you want?
 
Yes, you're right, it's just relating(=linking) objects by property. The semantics are defined in the application domain by the members of the list, not in a data dictionary maintained by the compiler.
 
Coming up with names for the lists can be hard. In fact, the name of the list is really the string of entries in list itself. Kind of reminds me of the name of God himself, which was the string of all the letters and words in the books of the Bible...
 
(God as the primary abstraction? Sometimes He is defined as "top" in the books, "top cat", "top sergeant"... the primary abstraction from which all others flow, a pure, virtual class.)
 
All the verbs having similar, oposite, or otherwise related meaning will be placed on the same list. A curious student is encouraged to push on the link to see what follows.
 
(It's sort of like an IQ test question, you know, which word does not belong to the list of choices?)
 
I want to keep the lists short, maybe 3, 4 or 5 entries each, otherwise the meanings start to diverge and you are left wondering what the idea was in the first place.
 
Opposites, like {love, hate}, {come, go}, {eat, drink}, {walk, run} are the most interesting categories and have separate lists.
 
The case of "being" {is, becomes, exists, appears, remains} is pretty tight.
 
Here is an interesting sequence.
 
γεννήθηκα - I was born.
μεγάλωσα - I was raised
πέθανα - I died
 
All three belong to different models, but are related by meaning. What is that meaning? Who knows, they just go together.
 
The curious thing about the morphology is that the first is medio-passive, because it refers to "self", like a reflexive verb, but the other two are active intransitives. (You'd expect them all to be medio-passive, but they're not.)
 
I'm definining them as I go. It's a blast.

 
On 7/2/05, Alexander Johannesen <alexander.johannesen@gmail.com> wrote:
Hi Joe,

I wrote:
> "Navigation should not be part of your datamodel nor dataset, but be a
> separate implementation detail. Here's how I'd do your XML stuff;
>
> <term id="some.id.x">
>   <label lang="en">Fiddle</label>
>   <label lang="no">Fele</label>
> </term>
>
> <term id="some.id.y">
>   <label lang="en">Chin</label>
>   <label lang="no">Hake</label>
> </term>
>
> And when you need a relationship between the two;
>
> <relationship of.type="played.on">
>   <member refid="some.id.x" role="instrument" />
>   <member refid=" some.id.y" role="method" />
> </relationship>

On 6/30/05, Joe Schaffner <schaffner.joe@gmail.com> wrote:
> I like your language, but I don't like making up names when they already
> exist. Each verb names its meaning already.

You can use your verb just as they are. What I'm more talking about is
giving each little schema (as in a microformat, really) an id which
you can refer to willy-nilly when you need it. It is not about making
stuff up if you've got some stuff that already makes sense, but what
it is about is using that stuff you've got the most optimally.

An ontology can be many things, but in your case it isn't the verbs
themselves but more what goes around them, like 'irregular verb',
'group', etc, meaning any other type of relationship you wish to
express.

> To me, "navigation" does not necessarily mean visual transversal. My program
> might like to iterate on the list, so the list would have to be named,
> formally, as in an XLink, whatever that might look like.

Any XML capable processor can do this without any problems, and this
is why I said you should make a clear distinction between your XML as
data and as visual system. By simply mapping all relationships between
your verbs you can later choose to create any type of interface or
processing rules, even using xPath.

> Pointers are indeed "hardwired" but they are intuitive, at least to me.

Have no idea why you feel they must be "hardwired", nor do I
understand what you actually mean by that. :) Any example?

> I'm working with a single data type which applies to all the verbs. I don't
> really want to define subtypes which merely model the structure of the
> verbs. The structure is basically the same for all verbs. Intransitives have
> no passive, Transitives should... some verbs are defective -- missing
> principal parts, but the missing parts can be null.

Then basically you create a typed dataset (verb X is of type Y) which
maps the relationships intrisically. It really is the same thing;

relationship X
  between verb A
  and type B

is the same as

verb A is of type B

with the difference that you can't refer to that relationship in the
latter example (you do this through reification in RDF and Topic Maps
using the first example).

> The navigation occurs on two levels, the visual level, the one we're already
> familiar with using HTML, and another, in fact, any number of logical
> levels. A verb could belong to many semantic categories, like transitives,
> intransitives, emotion, motion, being, mood, love, hate etc.

To me this sounds like faceted navigation system based on object
properties. Even if you have your verbs, surely you realise you must
define those properties? :)

> In other words, I'd like to keep the formal model as simple as possible: I
> want as few "types" as possible, maybe only one. Then I merely create named,
> linked lists which tie all the instances together.

Like ;
verb a, verb b, verb c, verb d (they're all just 'verbs')

and then
"silly verbs" : verb a, verb d
"cool verbs" : verb a, verb c
"funny verbs" : verb b, verb c, verb d

?

If so, that is no different to ;

verb a : isSilly, isCool
verb b : isFunny
verb c : isCool, isFunny
verb d : isSilly, isFunny

> A processing program
> would follow the links on a named list. Any verb belonging to the (semantic)
> category would be a node in the list. Any node can belong to as many lists
> as I want. The name of the list would be the name of the category.

What you're describing is just objects with properties, and you have
no semantics betwen your verbs at all (apart from them being typed).
Is that what you want?


Alexander
--
"Ultimately, all things are known because you want to believe you know."
                                                        - Frank Herbert
__ http://shelter.nu/ __________________________________________________





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS