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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Best Practice - beyond schema

[ Lists Home | Date Index | Thread Index ]

>An interesting best practice thread might be
>1. What CAN'T be handled with an authoritative transform?
"authoritative" meaning "as specified by the original (or agreed) schema 

As in, the named authority.  It might be any of a number of 
entities.  Conceptually, it is the cited owner of the 
record of authority.   One way to get the effect of locale 
is to cite the transform instead of the schema as authoritative 
over the local scope of effect.   The schema is an input 
to that.

>2. Given transforms, how much post-parse information really 
>   needs a more powerful schema formalism?  If so, when? 

>I'm sorry, I don't really understand how transforms effect the PSVI 
>requirement - can you elaborate?

If a PSVI or as Rick said better, a Typed Infoset, has an XML 
form, isn't it possible to convert to that form by transformation? 
If not, no.

>3.  What requirements for a schema language should be posed for 
>    any project and what should be explicit to a project?  It 
>    seems to me that we don't have many criteria for evaluating 
>    these proposed mods and features for schema languages?

>Some of these requirements may emerge during projects, I agree it would 
>be nice to list them for future use and better understanding.

The problem then is that we are seeing schema languages being 
proposed for which we have no use cases that result in 
requirements that can be evaluated.  How then does a developer 
or organization choose?  How can one take their project requirements 
and use them to contrast and compare to the capabilities of a 
schema language?  As in the trite but true scenario I outlined 
the other day, Step 3 (the recommendation from the technical 
team) vanishes into Step 4 (manager picks based on recommendations 
from inner peers).  There is a sort of cluelessness there that 
means dumb luck rules the project thereafter.   To ensure dumb 
luck has the best luck, the schema language ends up needing 
to be feature-rich and non-layered to cover as many dumb cases 
as possible.

>>I don't find it compelling to have a means to validate or 
>>augment that can't be inspected and proven by readily 
>>available means if it has to cited normatively.  That's 
>>the transparency requirement. But it also may just be my 
>>SGML Ludditism showing because I accept a lot of behind 
>>the scenes manipulation from my relational toolsets. 

>I think the effect of this utility works is obvious enough to count as 
>totally transparent. On the other hand more powerful tools might use the 
>same underlying technology and have equally open source, but eventually 
>the complexity of effect will take one to the other side of the 
>indeterminate "transparency v. opacity" boundary.

What is unrecognizable is unknown and it varies by context.  The 
context has to be the proof of effect where the proof is 
transparent.  In other words, it can be black box but the 
proof must be clear as to why it proves the case.  But my 
point is that I am being pristine about this technology 
because markup itself and XML specifically goes out of its 
way to get rid of layers that make it impossible to see into 
the box.  If we put those back, we have to confess that 
things like Typed Infoset, PSVI, etc, are the way back 
into the machine, the realm of XML Systems, not XML. 
This isn't all bad but it is a step past XML 1.0 to be sure.

>>>Flatten out one piece of the complexity carpet and darned 
>>>if another part doesn't ripple.  Try to rehost an MS Access 
>>>app into Visual Foxpro and watch code disappear into 
>>>the more powerful but explicitly relational language 
>>>features of Fox.  What goes on beneath the rug?  We aren't 
>>>supposed to care if the results are provably the same.
>>Shouldn't that be the case for the schema language processors?

>Yes, let's hope layering leads to a more complementary outcome.

I hope it leads to a more maintainable system where features 
can always be stripped away or added as needed.  On the other 
hand, there are very good reasons for tools like Visual FoxPro 
that have powerful and specific features for a specific application, 
relational database system building, vs say Visual Basic that 
has features for connecting to a relational database.  Not 
surprisingly, the relational aspects are easier in Fox, but the 
GUI aspects are harder.  Exactly the reverse goes on in Visual Basic. 
Jumping between the two can be exasperating.   I speculate 
that Typed Infosets which if pluggable become, Application Typed Infosets 
will offer the same dilemma: clarity in the specific application, 
obscurity with regards to general tasks.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS