[
Lists Home |
Date Index |
Thread Index
]
xmllint uses dtd's and works pretty well for simple stuff - it's command
line and should work with suse (i use it with fedora)
it's partner xsltproc is also pretty good.
http://www.xmlsoft.org
rick
Alexander Johannesen wrote:
>Hi Joe,
>
>On 7/5/05, Joe Schaffner <schaffner.joe@gmail.com> wrote:
>
>
>>Can you recommend an XSD validator?
>>
>>
>
>Not sure why you would want to do this in XSD, and I personally would
>use RELAX-NG, but even DTD is good enough for your simple stuff here?
>
>
>
>>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?
>>
>>
>
>Look up libxml and libxslt, which is what I would recomend, unless you
>want to do the whole Java thing, in which probably Saxon would suit
>your needs more than well enough.
>
>...
>
>
>
>>Today I was linking all the verbs which express "luck" - &tgr;&uacgr;&khgr;&eegr; - like: {&agr;&tgr;&ugr;&khgr;&ohacgr;
>>(I have no luck), &egr;&ugr;&tgr;&ugr;&khgr;&ohacgr; (I have good luck), &dgr;&ugr;&sgr;&tgr;&ugr;&khgr;&ohacgr; (I have bad luck),
>>&pgr;&egr;&tgr;&ugr;&khgr;&agr;&iacgr;&ngr;&ohgr; (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!
>>
>>
>
>Here's a part of your ontology ;
>
><item id="luck">
> <name>&tgr;&uacgr;&khgr;&eegr;</name>
> <name lang="en">luck</name>
> <type>expression</type>
></item>
>
>And here are verbs using that ontology (see '<type>luck</type>' ) ;
>
><item id="&agr;&tgr;&ugr;&khgr;&ohacgr;">
> <type>luck</type>
> <name>&agr;&tgr;&ugr;&khgr;&ohacgr;</name>
> <name lang="en">I have no luck</name>
></item>
>
><item id="&egr;&ugr;&tgr;&ugr;&khgr;&ohacgr;">
> <type>luck</type>
> <name>&egr;&ugr;&tgr;&ugr;&khgr;&ohacgr;</name>
> <name lang="en">I have good luck</name>
></item>
>
>The advantage is that you could use multiple types to declare other
>properties easily ;
>
><item id="&dgr;&ugr;&sgr;&tgr;&ugr;&khgr;&ohacgr;">
> <type>luck</type>
> <type>bad</type> <!-- also of a bad type -->
> <name>&dgr;&ugr;&sgr;&tgr;&ugr;&khgr;&ohacgr;</name>
> <name lang="en">I have bad luck</name>
></item>
>
>Now you can map your semantics between typed items to get that model
>you were talking about earlier. But you can also take a different (or
>additional) approach with this (very bogus) example to describe
>multi-relationships ;
>
><relationship id="3945">
> <type refid="morphology" />
> <item refid="&dgr;&ugr;&sgr;&tgr;&ugr;&khgr;&ohacgr;" role="medio-passive" />
> <item refid="syntax" role="schema-old-greek" />
> <item refid="reflexive" role="verb-type" />
></relationship>
>
>Now you can type your relationships, and chucking id's on the
><relationship /> you can talk about this relationships in other
>relationships, which would be *exactly* what you want if you wanted to
>give examples.
>
>
>
>>I want the metadata to remain in the application domain where I see it.
>>
>>
>
>Umm, isn't this just about where you store your definitions? Are you
>saying that you want to store your stuff in a C++ source file because
>that's where you want to maintain it? The what do you need XML /
>schema for? Just the presentation?
>
>
>
>>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.
>>
>>
>
>I'm sorry, I don't understand; what is maintained by the compiler, and
>what is meant by 'application domain' here?
>
>
>
>>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...
>>
>>
>
>this is what's known as ontology work, really; you've got some items
>and you try to pin a label on the group, defining what they're all
>about. After you've defined and defined some more, you got some kind
>of model to show for it. It sometimes work, and often it doesn't work
>at all. It depends on how good you are at flexibility.
>
>
>
>>(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.)
>>
>>
>
>Nothing -> something -> Everything :)
>
>
>
>>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.
>>
>>
>
>Why not create an interface that enables such behaviour by default?
>
>
>
>>(It's sort of like an IQ test question, you know, which word does not belong
>>to the list of choices?)
>>
>>
>
>Again, if you can define a context, all relationships within it can be
>described, but as long as you keep something in the compiler / C++
>source files and something in XML, this can be very hard to sort out
>and make useful.
>
>
>
>>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.
>>
>>
>
>Again, I think the idea of lists are going to fail you in the long
>run; there will be so many little lists with similar or opposite or
>near or totally wrong meanings. Why not define each verb with its
>relationships and let the application work out automagically what the
>model might look like? This way you've got a stronger foundation, and
>you don't have to worry about it at all.
>
>
>
>>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.
>>
>>&ggr;&egr;&ngr;&ngr;&eeacgr;&thgr;&eegr;&kgr;&agr; - I was born.
>>&mgr;&egr;&ggr;&aacgr;&lgr;&ohgr;&sgr;&agr; - I was raised
>>&pgr;&eacgr;&thgr;&agr;&ngr;&agr; - I died
>>
>>All three belong to different models, but are related by meaning. What is
>>that meaning? Who knows, they just go together.
>>
>>
>
>This is an untyped relationship where roles are undefined;
>
><relationship id="2356">
> <name>Somewhat related</name>
> <item refid="&ggr;&egr;&ngr;&ngr;&eeacgr;&thgr;&eegr;&kgr;&agr;" />
> <item refid="&mgr;&egr;&ggr;&aacgr;&lgr;&ohgr;&sgr;&agr;" />
> <item refid="&pgr;&eacgr;&thgr;&agr;&ngr;&agr;" />
></relationship>
>
>If you are on the page talking about '&ggr;&egr;&ngr;&ngr;&eeacgr;&thgr;&eegr;&kgr;&agr;', it will also list
>this relationship with it. If you now want to *talk* about this
>relationship ;
>
><item id="reified-2356">
> <name lang="en">The 'somewhat related' relationship</name>
> ...
></item>
>
>Simple.
>
>
>
>>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.)
>>
>>
>
>Define your ontology as such ;
>
><item id="self">
> <type>role</role>
> <name>reflexive</name>
></item>
>
><item id="active-intransitive">
> <type>role</role>
> <name>active intransitive</name>
></item>
>
>Now you can talk about these things in your relationships if you want to ;
>
> <item refid="&mgr;&egr;&ggr;&aacgr;&lgr;&ohgr;&sgr;&agr;" role="active-intransitive" />
>
>Migth make a nifty user-interface to your dataset.
>
>
>
>>I'm definining them as I go. It's a blast.
>>
>>
>
>That's the key, isn't it; have fun! :)
>
>
>Alex
>
>
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
