RE: question for Kirill

  Sounds like some specs allow you to define your own module.  Thus, it 
seems to me that we could add a checkpoint to address on rules for defining 
for modules - similar to one we have in profiles.

lynne


At 02:24 PM 4/18/2003 -0700, Kirill Gavrylyuk wrote:

>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 20:44:28 UTC