[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML and XPATH: How do they work?


xml schema refid
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@g...> 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@z...
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
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.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.