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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: SAX: ModSAX addition, general property query

[ Lists Home | Date Index | Thread Index ]
  • From: MikeDacon@aol.com
  • To: david@megginson.com
  • Date: Mon, 8 Mar 1999 17:26:32 EST

Hi David,

In a message dated 3/8/99 12:19:24 PM Eastern Standard Time,
david@megginson.com writes:
> Yes, but what about filters that perform specialised actions?  And
>  what about adding support (stable or experimental) for new XML-related
>  features like schemas, datatyping, and linking as they become
>  available?

You are absolutely right that extensibility is important. And, as
you also stated, both naming schemes provide that ability.
>  As I wrote before, it doesn't much matter whether we use Java property 
>  names incorporating domain names (like
>  'org.xml.sax.features.validation') or URIs (like
>  'http://xml.org/sax/features/validation'), as long as we have the
>  ability for people to create new names without fear of collision.

Why do you need a domain name in there?  I think one Parser/Filter implementor
would be loathe to implement another companies feature name if it had
sun.com or microsoft.com in it.  That was the chief problem that developers
had with Sun naming the Swing package com.sun.swing.  I thought your
features would have a single root tree like:


So that all features would be:


as well as 

sax.props   (for properties)

Now, I understand the domain name being in there is a piggyback off of DNS.
But, I still believe that functional features (of both Parser and Filters) are
finite domain -- whereas the web is not.  That is why I don't see the
between this feature set and XML namespaces.  If you agree that features and 
props are a finite domain (and in the whole scheme of things a rather small
then a single naming tree should suffice.

Also, Daniel Brickley mentioned a Java bias.  I can understand his
concern; heck, let's separate them with the delimiter of your choice
(hyphens, underscore, etc.).

While we are on the subject of bias: a URI has a resource/file system 
bias.  To me, that bias was just confusing (and overkill) for something that 
I felt was best expressed with one word String constants (if you added 
the initial default set to the interface).

Lastly, I would like to say that I do like your idea for the general 
property query and am glad you proposed it.  The naming concerns I
express here I deem as minor issues.

Best wishes,

 - Mike (mdaconta@aol.com)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


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

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