-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Je Mon September 9 2002 07:37, Hussein Shafie skribis:
> > One of the goals of XXE is (or should be, because it is a critical goal
> > for wide acceptance) to hide as much as possible the document structure
> > details from the user.
>
> I'm convinced that this is not possible or at least very, very difficult
> to achieve.

Difficult: absolutely.  Impossible: I don't believe so.

> DreamWeaver, FrontPage). Do you know any generic XML editor which
> *really* succeeds at "hiding as much as possible the document structure
> details from the user"?

I think XXE does it better than anything else I've seen so far, and to be 
honest, it is pretty close.  Certainly, hobbled by DTDs, there is only so 
much XXE can do.

> I also often ask myself (by laziness, probably to justify our approach,
> etc) is this feature really desirable?
... [blythely reording the quotes]
> I understand. I hope that by customizing XXE you'll be able to partially
> implement what you describe for a specific DTD (no programming involved:
> just macro-commands specified in configuration files. This will be
> described in the Power User's Guide.)

This is interesting.  I look forward to seeing this.

In answer to the question of desireability, yes, I believe so.  I'll give two 
reasons:

1) If you don't, you'll get limited acceptance.  You may draw TeX users, or 
the XML nuts like myself... but you won't get anybody converting from Word.  
Believe me, I tried at my last contract to get people to use XML as a 
standard document format so that we could manage critical documents 
centrally.  It was impossible to get buy-in, because of the relative 
difficulty of the existing XML document-oriented editors (Morphon, at the 
time :-/).  XXE is loads better, but knowing that group of people, I don't 
think it is quite to the comfort level where they'd accept it as a substitute

Notice that I do believe that, even if it isn't a "Word" experience, they'll 
be willing to cross over.  Many professional end users, I've found, aren't 
sticklers for having a Word clone if you can argue the benefits of a better 
document format, such as XML docbook -- as long as the tool is sufficiently 
easy to use.  If it is painful to use the tool, only masochists will use the 
tool.  Again, these people don't care about the fact that the document is 
docbook, except peripherally -- they just want to be productive and write 
documents.

Another assumption I'm making for this point is that you even care about 
getting average users to use XXE.  You may not, which is your prerogative, 
and in which case, this point is moot.

2) The world has more than enough tree-oriented XML editors.  XXE is a 
document-oriented editor.  I believe that this difference in perspective 
makes all the difference.  The assumption is that people are using XXE as a 
word processor.  The document structure itself is incidental.  If you could 
find a way to completely hide the document structure and maintain its 
validity, wouldn't this be valuable?  In the end, for most documents authored 
with XXE, the use is going to be in some human-readable visual display.

> > However, adding just the legal ancestors to the list
> > I think is a reasonable compromise because the number of extra element
> > choices will always be relatively small
>
> It depends on the DTD/XML Schema.

I'm only talking about adding the direct ancestors which can legally follow in 
the document.  How deep are the elements being stacked?  10?  100?  I'd be 
surprised if you could show me a /document/ oriented XML document that has a 
child that is more than 10 elements deep ... IE, count( ancestor-or-self::* ) 
> 10.  I'd be /really/ surprised if you could show that this is common :-)

Now, it may be significantly time-consuming to determine which ancestors can 
be legally inserted somewhere in the document -- I don't know how you're 
doing validation internally.  However, the number of elements added to the 
list will remain small. 

A better argument against my request is whether the ease-of-use benefit of 
adding this outweighs the confusion it might produce.  I don't know.  I 
believe that it would be more useful than confusing, but I don't know.

> But in the short term, we don't have the resources to experiment this
> idea using a native implementation. Sorry.

I can understand.  'Course, you could make the source-code available and I 
could take a look at it myself ;-)

- --- SER
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9fJTkP0KxygnleI8RAgMcAKC2/+ZaxcVKkHMV1+nZ65s0nVhTcwCfXLPG
FEmNpA4JRcwwjzxcz1NBjP4=
=LYeE
-----END PGP SIGNATURE-----

Reply via email to