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-dev] Re: determining ID-ness in XML



>     4) Accept from the outset that processing--and therefore 
> the processing
> model, its order of operations, and the particular form of 
> data input which it
> expects and the 'natural' data structure which is its 
> output--are inherently
> matters of local expertise and local need at each processing 
It seems to me that 4) is the most viable course, and reenforces Tim B's
catechism of "It's the syntax, stupid". The basic core should focus on
providing a common syntax for expression. 

For instance, I would dearly love Namespaces to be synonymous with domains,
but there's a whole class of other developers that want namespaces to
provide no more than a disambiguation mechanism. 

Because namespaces are merely syntactic, however, I'm free to associate
domains with namespaces and no one's the wiser. There may be enough of us
with this one desire that we formulate a standard that states
"namespace==domain", because it's convenient for data model processing. I
would think it possible to add such an association without burdening those
who treat namespaces as mere syntax. Of course, I tend to be naive-- but
hope springs eternal.

Once you start rolling in PSVI and validation and ids and what-have-you, you
force compliance to mechanisms that maybe only just so many people are
really interested in paying for in terms of added complexity. No argument
here that one does get cleaner integration going that route; but there's
those simpleton's like myself who just want easy-to-use tools with high
domain leverage and thin user's manuals. If I have to get down and dirty
with a complex tool, then it had better do a lot of my work for me. Ahhh,
well, now I'm ranting...

Now I see that Mike's just posted a fifth alternative. I'll take 1 from
column 4 and 2 from column 5...


>  4) Accept from the outset that processing--and therefore the processing
> model, its order of operations, and the particular form of data input
which it
> expects and the 'natural' data structure which is its output--are
inherently
> matters of local expertise and local need at each processing
> node. Let those
> who promulgate general specifications define the thinnest 
> possible layers
> precisely to have the greatest possibility of having each of 
> them accepted for
> the greatest range of divergent uses by the widest variety of 
> processors. This
> means that the form of integration and the specific 
> interdependencies of
> various specs will inevitably vary by implementation, 
> precisely so that they
> can be arranged to produce the results required by each 
> different processor.
> The ultimate implication is that no upstream creator of data 
> may impose its
> intent on a downstream processor. Regardless of which of the 
> 256 (or 2048, or .
> . .) variants of processing that an XML documents may have 
> been created for,
> the point of each processor's individual expertise is that 
> the same variety of
> possibilities is open to every subsequent processor of that 
> document, in order
> to achieve its particular goals.
> 
> Respectfully,
> 
> Walter Perry