OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: XML Schemas: Best Practices



Short answer:

No recommendation.  Practice must suit requirement.

********************************************

Long answer:

It depends as I said before on whether the 
type maintenance is needed and will be expressed 
in the schema say, vs constraints expressed in 
an application rule.   

IOW, the question is really, when does one 
need abstract types?  Obviously, abstract types 
means someone has been negotiating an abstraction 
(a compression of representation).

If the hard requirement is for variable content 
from non-communicating sources, you are down 
to the OR group (doesn't care - it groups, it doesn't 
compress the representation).   

Aside from compression, you have to ask 
yourself what you are going to do with the schema 
over time.   IMO, a Best Practice can't be divorced 
from the rules of the environment of the practice 
of combining sources.  My experience heretofore with 
SGML was that systems needing DTDs needed agreements  
apriori.  That is what makes them tough to build; 
the politics of agreement, but this was before XML 
became a messaging format.  In SGML, it was a contract 
among companies or customers to enhance lifecycles 
for documents.  That is the real reason only 
the bigGuys did it.  Few others needed it enough 
to pay for it. 

On the other hand, when I've had to 

o  initialize an authoring system with it (eg, think 
ArborText or Softquad editors that are DTD enabled)

o  aggregate in a stylesheet enabled player which 
got rid of the need to downtranslate (eg, to HTML)

and there are multiple, equal authorities controlling 
the content, I used the OR group to switch sets in and 
out.  In an situation with equal probabilties, the 
rule of choice is an external authority/system (eg, the 
workflow system rules the content of the document).

Using the OR, a DTD controls a set of multiple document types that 
share sub-trees.  The choice of type depends on the 
what content type is requested.   I did this both for US Navy 
Work Package systems (CASS) and US Army DTDs for IADS 
because each of the document families was as you say, 
under different controlling authorities but the actual 
document had to be authored as if it were one document.  The only 
reason to combine them was their contents are shared 
in the target player (IADS in the second case) which 
was stylesheet-enabled and frame targeted, or the authoring 
tool used by one group all the time (CASS).  In other 
words, we were not downtranslating; we aggregated.

That is quite a different issue from using a schema 
as a sort of object hierarchy declaration or to feed a 
transform.  In short, remember that a schema is a 
formal description and the "bestness" of the practice 
has to be defined in terms of the environment of 
the requirement of use or the local rules of the 
thing described.  We have multiple means because 
we have multiple overlapping but distinct requirements.

BTW: I've never cared for entity based 
modularization.  It is ugly to teach, ugly to use, 
and ultimately, it seems, only helps the DTD maintainer 
keep up with abstract grouping names.  I prefered switching 
tags that at least make the GUI look more sensible 
by clearly showing it was a choice, not an object.
 
PE modularization has always looked like a hack to 
me; useful but asserting the DTD is a better description 
than it actually is.  I am in the minority on that 
position because switch tags result in crud in the 
file which the semantic or style processor has to ignore. 
Some early systems used to stick a non-displaying but 
format affective (space, line end, etc) in there anyway 
and the rules for the formatting stylesheet could get ugly 
keeping that out.  On the other hand, say using XPath, a 
switch tag can be convenience.   We ended up with 
them in X3D to make the multiple encoding madness 
easier to live with, thus

<children>

is in there although one wishes it weren't.  Now that 
schemas enables abstract types (X3D is an abstract 
node language from the get go), we can make those 
go away.

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Roger L. Costello [mailto:costello@mitre.org]

Of the 3 methods, which one would you recommend for Best Practice Curt? 
Len, what's your recommendation?  /Roger