XML

Hui Zhou zhouhui at wam.umd.edu
Wed Feb 2 06:32:31 PST 2005


Hopefully Jeremy doesn't mind I open a new thread with old topic :)

On Tue, Feb 01, 2005 at 10:54:28PM -0700, Kevin P. Fleming wrote:
>Hui Zhou wrote:
>
>>As I tried to express, even with XML, it can be extremely simple 
>>that I
>>can comeup with a parser overnight without dependency or it can be
>>complicated enought for me to spend weeks to study the w3c spec. Its
>>like it ranges from scooter to full size hummer. The hummer comes 
>>with
>>higher maintainence albeit brings extra whistles. My philosophy is 
>>to
>>stay simple and know what I need.
>
>Will your simple parser handle:

Thanks, Kevin, I love detailed discussion.
>
>- XIncludes, or some other means of building a combined profile from
>lots of little pieces

I would say it suffices to restrict individual piece to be a package.
Check out my old profile:
	http://dragontiger.dyndns.org/download/lfs.gm
lfs is treated as a package, which include subpackage ch5_pre, ch5, 
ch6_pre, ch6 and ch6_post, each inturn may have subpackages. My parser 
or tool seraches the package name inside its inventory, if not found, 
look for individual profile within a directory hierarchy.
	So I have the freedom either use a whold profile for all the 
packages, or optionally make it little pieces with each piece 
essentially a root node within the top package.
	So the answer is yes.

	And It not necessary has to be myway, there are many other 
intuitive, easy way without learning this:
	http://www.w3.org/TR/2004/REC-xinclude-20041220/
which is another 30 pages!

>- character encoding, to allow the user to be able to put entity 
>values
>into their profile using their native language/encodings

Do we really have the urge to support - say Chinese (my first 
language) -? If there is, that can be added in. That is just simply 
increase the profiles character set, in most case, trivia.

However, I seriously doubt the need.
>
>- validation to ensure that already-known required elements are 
>present
>(for example, a [copy] element missing a [source] or a [destination])

I shouted several times that validation is unnecessary. Thanks for the 
example, I will explain.
	After parsing, or during parsing, the tool will barf on 
missing source or destination under copy. He does not need a dtd to 
tell him, because without source or destination, he wouldn't know how 
to do it; even say, the dtd (faulty maybe) says its validate, the tool 
will barf because it doesn't make sense. 
	And for example, the tool takes defaults, the tool work 
happily with the copy on missing destination if a default destination 
available, there is nothing wrong there.
	Missing destination under copy is not a very common mistake a 
profile writer will make, make typos in the destination is common. 
Validation won't help you here.

	It is quite arguable do we need split a simple "cp src dst" 
into three entities and make the profile worry about 6 tags including 
3 matching '/'s.
	
    I implemented my tool in less time that I was able to learn DTD.

>- additional attributes added by the user for their own needs, but
>ignored by the alfs tool
    
    Do you mean will my parser or tool ignore those extra attributes 
or tags?
    I don't use attributes. Attibutes are implemented as subnodes 
under the parent nodes. I find it suffice.
    Yes, my tool lives happily with extra tags he doesn't understand 
as long as they don't hurt (no, they do not).
>
>All of these already part of standard XML (with the addition of
>XIncludes), and handled correctly by every compliant XML parser. 
>These
>are also things that we know we already need, because we have been 
>using
>them and they have been beneficial. While the profiles could 
>certainly
>be built without them, there are good reasons to continue using these
>features.

Beneficial? I had quite some pains on editing the profiles 2 years 
back. I have the same problem as Gerard that we don't generally want 
to follow the book.

Good reasons? May I hear more? in specific detail.

-- 
Hui Zhou



More information about the alfs-discuss mailing list