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: Enlightenment via avoiding the T-word

>> Oh, I now understand the reason why some people want unique 
>element names :
>> you can associate elements to types without validating, just 
>by looking up
>> in a type table.
>Validation and unique element names are not tied together 
>here. In fact,
>validation has nothing to do with it. The question of whether element
>names are unique or not is simply one of how complex/context-dependent
>your type lookup code is.

I agree. I was just meaning that a "smart" validation operation was able to
build a PSVI even with context-sensitive local elements, so I didn't see the
point of enforcing unique local element names. Then I realised that some
people simply wanted to process type information without even validating
their document.

>In a closed, trusted system, some people would consider it robust.
>Others would not. It's a religious argument I'd rather not get 
>into. (In
>an open or untrusted system, it is definitely not robust.)

Agreed. Plus, we still have to define the term "robust". I was once told
that an XML processing program was robust if it could keep on processing
data the same way even if new elements were added to the schema, the program
just ignoring them. I replied that a bill processing program could not be
considered robust if we simply added a "<fake-bill/>" element to the schema
for testing purpose, and that the program still processed bills marked as
fake just as normal bills. Robustness is not an easy thing to define ; AFAIC
it would be difficult to achieve without relying on a kind of schema for
document I/O.

>> Plus, I'd be
>> very interested in seeing applications that process PSVIs or TIs in a
>> context-insensitive way. What kind of applications could it 
>be ? Do you have
>> examples in mind ?
>Mostly simple type-processing stuff. For example, I could convert all
>dates and real numbers to a specific format before storing them in a
>database, so a type-unaware query language could be used against them.
>Or I could write standard routines to process given types as part of a
>data binding application. It's all really just plumbing that fits
>beneath the context-sensitive stuff.

OK, but there again I think that not wanting to rely on validation is a
threat. Do we know what is the impact of validation on performance, anyway ?

[ the funniest part in this thread is that most XML processing we do right
now is done without schemas ; we need proper tools here before introducing
them... ]


>Ronald Bourret
>XML, Databases, and Schemas
>Speaker, Geek Cruises' XML Excursion '02
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.xml.org/ob/adm.pl>