RE: includehosts mandatory?

Hi, just to confirm, I am fine having it optional.
It increases flexibility by expanding to non-host based IRI (although I
wonder if I would not have to find an ISBN number on some host after
all).
As for mandating it, if somebody want's to use it, why not?
In the worst case the DR created by a user is useless because it has no
scope, but that does not make the mechanism of a DR bad.


Kai



> -----Original Message-----
> From: public-powderwg-request@w3.org 
> [mailto:public-powderwg-request@w3.org] On Behalf Of Phil Archer
> Sent: Thursday, June 05, 2008 1:34 PM
> To: Public POWDER
> Subject: Re: includehosts mandatory?
> 
> 
> Good. Thanks Kevin.
> 
> Unless others chime in arguing /for/ includehosts to be 
> mandatory, then let's leave it as optional. It's worth noting 
> that pretty well every example in all the docs does include 
> it so it's very prominent in the documentation.
> 
> P
> 
> Smith, Kevin, (R&D) VF-Group wrote:
> >  >> You're saying that we already need a 2-step validation 
> and that we 
> > can therefore check that an IRI set definition is not empty without 
> > having to mandate <includehosts>? That would be good I think.
> > 
> > Exactly, so -1 from me for a mandatory includehosts.
> > 
> > -----Original Message-----
> > From: public-powderwg-request@w3.org
> > [mailto:public-powderwg-request@w3.org] On Behalf Of Phil Archer
> > Sent: 05 June 2008 12:21
> > To: Public POWDER
> > Subject: Re: includehosts mandatory?
> > 
> > 
> > 
> > 
> > Smith, Kevin, (R&D) VF-Group wrote:
> >> Hi Phil,
> >>
> >> My understanding was that if we support other identifiers (ISAN, 
> >> ISBN)
> > 
> >> etc. then <includehost>s would not be relevant for those, only for 
> >> those retrievable over the Web.
> > 
> > True - but POWDER-BASE only has <in/excluderegex> with no 
> other child 
> > elements allowed for <iriset>. Things like ISAN numbers 
> would exist in 
> > a a format that is not POWDER but that can be transformed into 
> > POWDER-BASE. Therefore the question about <includehosts> 
> only applies 
> > specifically to POWDER and not BASE or S.
> > 
> >> NB a thought to park for now: so you could describe the 
> >> characteristics of a bunch of SMTP addresses using POWDER, 
> couldn't 
> >> you? That seems quite powerful.
> > 
> > Yes indeed, and POWDER-BASE can do that, therefore 
> conformant POWDER 
> > Processors can do that which is, I think, at the heart of 
> the Stasinos 
> > plan.
> > 
> >>>> It gives us a way to ensure syntactically that an IRI 
> set is never
> >> empty
> >> It seems like we will need two-step validation due to some 
> features 
> >> absent in XML Schema, so this could be picked up by an additional 
> >> check (we've mentioned using XSLT as a way to enforce 
> business rules, 
> >> and also to create a neat HTML page teling you what the DR says in 
> >> plain English).
> > 
> > You're saying that we already need a 2-step validation and 
> that we can 
> > therefore check that an IRI set definition is not empty 
> without having 
> > to mandate <includehosts>? That would be good I think.
> > 
> > P
> > 
> > 
> > 
> 
>

Received on Thursday, 5 June 2008 11:51:05 UTC