[XML-DEV Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
RE: XML and XPATH: How do they work?
Saxon-SA offers both an XSLT processor and a schema
validator that are easily invoked from the command line.
To validate a schema:
java com.saxonica.Validate -s
schema.xsd
To validate a source document against a
schema:
java com.saxonica.Validate source.xml
schema.xsd
To run a transformation
java com.saxonica.Transform source.xml
style.xsl
Michael Kay
http://www.saxonica.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
http://modern-greek-verbs.tripod.com
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@g...>
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@g...>
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/
__________________________________________________
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
RSS 2.0 |
|
Atom 0.3 |
|
|
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
|
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please
click here.
|
|