RE: question for Kirill

First of all I don't think we have a flaw. I agree with Lynne and I
think this is pure editorial/readability issue, but important one.  

The issue is close to 1). It is all about granularity and integrity of
extensions.

Many technologies (SOAP , WSDL) are designed as an extensible frameworks
into which modules can be plugged in. You don't have to implement any of
such pluggable modules to conform to the spec, but if you want to
support, you have to conform according to the module conformance
requirements. Main spec in it's turn provides some of such modules.

So it's not a granular extensibility where you're free to add function
by function. Your module spec actually has to conform to certain rules
and is monolithic - cannot be implemented by parts. 

In case of XHTML, I could easily add one function - a granular
extensibility.  But it can't be called a module, at least not in a sense
of our Module definition (a "grouping").


 



> -----Original Message-----
> From: Lofton Henderson [mailto:lofton@rockynet.com]
> Sent: Friday, April 18, 2003 2:13 PM
> To: david_marston@us.ibm.com
> Cc: www-qa-wg@w3.org
> Subject: RE: question for Kirill
> 
> 
> At 04:19 PM 4/18/03 -0400, you wrote:
> 
> >Kirill wrote:
> >
> > >Our current definition may leave impression that a technology
always
> > >has a closed set of modules.
> >
> >It sure does. I think that was the intent. We were thinking of
modules
> >in the sense proposed for XSLT 2.0 (core, serialization, schema
> >awareness, backward compatibility, etc.).
> 
> I was thinking of it in the XHTML Modularization sense.  It took a
> monolithic collection of functions from XHTML 1.0, and divided it into
a
> bunch of subsets -- the modules -- that are building blocks for
writing
> profiles.  Here (as I recall) there is no single Core module.  However
> there is a collection of modules that comprise a minimum for any
profile
> that gets a certain defined goodness rating from XHTML (that is a rule
for
> profiles in XHTML -- "any good profile contains at least these
> modules...")
> 
> (Haven't studied XLST 2.0 closely, so tell me if I'm violently
agreeing
> with you.)
> 
> 
> > >I think we could add to the note for G5 that spec may allow for
> > >additional modules, should define extensibility framework and
> > >conformance requirements for modules to be added.
> > >An example could be SOAP Messaging Framework (SOAP Part 1) and SOAP
> > >Encodings. SOAP Part 2 defines one SOAP Encoding (also called
> > >"Section 5"), a module according to our definition.
> >
> >Isn't this more like an extension? XPath comes with a set of
functions,
> >and you can add in more functions, but the rules constraining the
> >added functions are extension-type (GL 9) rules.
> 
> I'd like to clarify Kirill's original statement, "also allow for
adding
> more modules following certain extensibility framework. Our current
> definition may leave impression that a technology always has a closed
set
> of modules."
> 
> Question:
> 
> 1.) does this mean adding new functions via extensibility, and
collecting
> those into new modules?
> 
> 2.) or, does it mean imposing a new modularization on the set of
functions
> that are standardized in WS?
> 
> (Okay, or "3.) both"  -- i.e., there could be hybrids, but let's
ignore
> them for a minute.  I think you see what I'm trying to sort out.)
> 
> -Lofton.

Received on Friday, 18 April 2003 17:24:39 UTC