See also:IRClog
<Norm>namespaceDocument-8background NDW 5 Mar
NW: We've gone around on this severaltimes, decided we would benefit by resetting and consideringrequirements from the ground up
NW: NS documents are sometimes usedby agents (people and mechanical)
... Competing demands on what should be there
... No single thing (XML Schema, RDF, ...) will satisfyeverything
... When we first looked at this, we thought maybe a single XMLformat (e.g. RDDL1) would do the job
... But the world has moved on, and maybe we don't need to doanything
Tutti: We should try to dosomething
NM: But maybe we'll decide wecan't
NW: Two options at least: Do someform of RDDL 2 (a single XML vocabulary) designed for the purpose;pursue the route set out in the original finding (focus on an RDFdesign)
TBL: Let's standardise on threethings: For the self-desc. web, Semantic Web wants RDF-XML, OFWebwants XML or DTD or Schema....
... If you stop putting schema doc as the NS doc't, you raise thebar for applications to have to understand more than you wouldotherwise
... Imagine web-based python -- would we want to say they all haveto have XML parser
DC: XML Schema have already raisedthe bar -- they already use RDDL, the cost is paid already
TBL: Opposite for SemWeb
NM: Fundamental question is that if Ihave in my hand an NS URI, will I always wantone thing from it,or different things in different situations
... Yes, maybe content negotiation would help
... So, e.g., sometimes a schema and sometimes the GRDDL-producedRDF
... The value of the purpose/nature stuff allowed additionalfunctionality -- how important is it to suppport that?
... There's also the performance issues
... Must not be a requirement that every time you do a validationyou must do a GET
RL: Conneg got mentioned, if wethought of the different metadata as all being representations ofthe same resource
NM, HT: Seems stretching to say that wrt e.g. aspec., a schema and some GRDDL
TBL: It's a violation of thearchitecture
DC: Works for GRDDL itself (RDF andHTML)
TBL: Itcan be OK, but it is likelyto not be always
NW: Consider the DocBook NS -- whenwe get to the NS document, we're going to find stylesheets forusing it, DTD, RelaxNG schema, User guide
... RDDL is sort of working for much of that, and with GRDDLcoming, the SemWeb software should be able to win too
<Noah> Hmm. Norm says some ISPsdon't support mod_negotiation. Interesting. I wonder whether weshould juice up the Generic Resources finding to say: those whoadminister servers likely to be used to host generic resourcesSHOULD support conneg, perhaps with a Norm/Nadia story telling howNorm couldn't use conneg because his ISP wouldn't let him.
TBL: So GRDDL would extract from theDocBook NS doc't a bunch of triples telling me where to findwhat
... But I don't expect to ever point a SemWeb tool at the DocBookNS
NW: Consider the VCard namespace -- Iexpect in due course there will be lots of stuff there, includingRDF, tutorials and HTML description
TBL: That's fine with conneg
HST: I don't agree --- this is likeDocBook, not GRDDL -- lots of different kinds of resource, connegnot appropriate
TBL: The tabulator will find NSdocuments, would have to indirect via GRDDL -- I don't want to haveto do that
NW: For some namespaces that's OK
DC: This is an argument for doingnothing
HST: I think the current XML Schemasituaiton is a good model -- if an NS owner has only one thing tosay, or a few things which fit with conneg, no need forindirection, just put it/them in place
... but if need to do more than that can handle, TAG provides astory via an RDF vocab. and so on (per the draft)
DC: That works for me, indirection isa necessary evil
... Consider XQuery F&O -- they designed it for their needs,but with my SemWeb hat on I get lots of value out of theirURIs
... currently there's an HTML doc't at that NS, NW will turn thatinto (G)RDDL -- how will I get what I want, which is label,description, domain and range for each ID in that namespace
... How will I do that?
<DanC_lap> .http://www.w3.org/2006/xpath-functions#
NW: Not clear that the current storycan do this
HST: What we can do is for {NS}#foo,use (G)RDDL to say -- look at {metaforNS}#foo for RDF
<DanC_lap> fn:abs rdfs:rangesomething:numeric; rdfs:label "abs"; rdf:typeowl:FunctionalProperty.
DC: Look at the XPath f&o NSDoc't [URI above]
... The HTML tells me what I want, but I want it RDF
NM, TBL: [rathole wrt I18N]
TBL: The label is different from theURI
[rathole continues]
NM: I remain unconvinced why anyonewould want to spell 'sum' any way other than 'sum' -- it's likeprogramming language
<Zakim> Stuart, you wanted tomutter about suspension of disbelief on NS and NSDocument beingdifferent resources
NW: I could give you what youwant
DC, NW: via conneg? yes, via conneg.
SW: I think we're talking about NSand NS doc't as if they were the same thing
... but they're not
DC: So they haven't given you any wayto distinguish namespaces and namespace documents
SW: I can suspend disbelief aboutthis, but I'm surprised TBL is
NW: I think [the DocBook NS URI]identifies (the concept of) DocBook
HST: That will upset NM
NM: It's a bad idea in general toassume that NS names identify languages as well as namespaces
... An NS ownermay say that, but don't build software thatassumes thatall NSes are like that
... because, among other things, languages and NSes are notone-to-one
... HST made a proposal 15 minutes -- use conneg for a broad rangeof things
HST: [interrupts] that's not what Iproposed, rather, use conneg iff all the things you have to offerare reprs of the same thing
NM: Fine.
TBL: This all just convinces me thatwe need to get on to the Arch of the SemWeb, because the answer tothis topic comes at least in part directly from there
... So, as per SW Best Practices, put RDF at NS URIs
... for SW purposes
... and for non-SW purposes, do something else
NW: So what do I do for DocBook?
TBL: Well, I don't use e.g. XMLSchemas, so I'm not sure what they want
NW: So, we decided that for the sakeof interop
TBL: Interop with whom?
NW: Across the board
... Are you happy with what HST said
... And in particular, using conneg between an HTML doc't andRDF?
TBL: Yes
... What you couldn't do is conneg between an XML Schema and an RDFontology.
NM: If you have an OWL ontology, it'snot describing a schema, for sure
... Consider DocBook -- we retrieve XML, we use GRDDL, we gettriples
... Could you ever want a schema for the docbook language and RDFassertions about those GRDDL-generated triples
... GRDDL is a bridgepoint
HST: Theonly bridgepoint
TBL: There's another one -- quotedXML in the midst of RDF
NM: So GRDDL allows us to get triplesfrom a purchase order
HST: [confusion]
TBL: You can get GRDDL from theschema, for instance
NM: So, from a purchase order in XML,I can find the GRDDL and apply it, to get triples I can use
... I also have a schema, which describes the syntax of thelanguage
... So shouldn't I be able to get the ontology for the languagefrom somewhere nearby the schema?
TBL: Maybe you could, but myassumption is that the RDF you get from GRDDLing the po will drawon many ontologies, e.g. amount of money, lat/long, etc.
NM: So my story about languages isexactly the same, that languages may be made of multiplenamespaces
<DanC_lap> (pun: namespacedocument vs namespace)
HT: What is the nature of theresource identified by a namespace URI?
... If it's not an information resource, you should not return itwith a 200.
DC: Dicussing this in the abstract ischallenging.
HT: Let's pick the XML Schemanamespace URI
... At the moment, if you retrieve from that you get a 200, youwill (soon) get a document with anchors for every name in theschema namespace.
... It's what we might call English metadata, I.e. summaries orpointers to what the Schema rec says about them.
... It isn't the namespace, clearly.
... I am assuming that the things identified by NS URIs are notinformation resources.
DC: That's inconsistent with whatdata you're presenting.
TBL: Using your email address toidentify you doesn't mean we think you're an email address
<Zakim> timbl, you wanted to syit is an information resource and to
TBL: I like the pun, because I likegetting 200s, because I want information
... there's this additional convention/engineering approach,involving #
... So wrt the XML Schema case, I'd say the URI identifies adocument
DC:But it's a namespace URI
TBL:It's called a namespace name
<DanC_lap> ("namespace URI" isone standard term; "namespace name" is another. cfhttp://www.w3.org/TR/2006/REC-xml-names11-20060816/. "http://www.w3.org/2001/XMLSchema"is a namespace name. Tim stipulated that it's a namespace URI;that's pretty darn close. I can buy the punning story he told, butwe should also stipulate that it's a very liberal reading of thenamespace rec )
HST: It says in the XML Schema spec."The namespace URI for the XML Schema namespace is 'http://www.w3.org/2001/XMLSchema'"
TBL: We use the word 'namespace' torefer to either the set of terms defined in the namespace, or inRDF to refer to a set of URIs which share the namespace URI
TBL: but the concept of the setdoesn't come up in the architecture, so the fact that we don'ttreat the namespace URI as identifying that set isn't a problem
DO: In dealing with purchase ordersin the real world, getting the schema isn't hard, but isn'tinteresting either
... the hard part is getting at the meaning and significance of theterms in the po
... there's also all the contractual implications
... So I think going from schemas to the semantics of POs is toosimplistic
<Zakim> Noah, you wanted to say Ithink I would prefer to say namespaces are information resources,probably a set of names
NM: I think there's semweb info atboth levels
... If we get some GRDDL-derived triples from a PO document, whichsimply says locally what the PO says, whereas the complex stuffabout theimplications of that is global and, indeed, much morecomplex
... But both are useful, and the first can be associated iwth theschema
... TBL, it feels wrong for me to say the NS URI identifies adocument
... I think wecan say that the Namespaceis an informationresource, and it's a set of names
... because we say an info resource is something which can befaithfully represented in a document
... So returning 200 plus a document is OK, because you canfaithfully represent that set in a document
<timbl> NM, do not confuseinformation about a set with the set. Info about the set is an IR,the set isn't IMHO
NM: So as long as a document is arepresentation of the set, it can participate in conneg wrt the NSURI
... I think that's simple and robust
NW: Back to the finding
... We were close to agreement on "sometimes conneg will do,sometimes you need indirection" and "if you need indirection,here's how"
<Norm>Snapshot of whiteboard
TBL: I want to exempt the RDFOntologies
HST: You don't need to, it's coveredby the first clause -- if you have only one thing to say, just sayit
That is, only one representation is triviallyusing conneg
NW: Consensus?
NM: Reserve my position wrt the finalbit, i.e. our approach to providing the indirection
NW: So, I think I understand what thereason my proposal on the indirection failed last time -- there wasan asymmetry between [x] and [y]
<Stuart>http://lists.w3.org/Archives/Public/www-tag/2007Mar/0012.html
NW: [summarises the above email]
DC: You asked for RDDL docs from thecommunity, did you get any?
<Norm>Summary of RDDL usage in the wild
HST, DC: [try to work through what a vNext schemaprocessor would do]
NW: I'll try to come up with aspecific example over the break
<Norm>BPEL RDDL doc't
DC, NW: [working on whiteboard wrt the RDDL forbpel, and for RDDL itself]
<timbl_> The example discussed inthe break was RDDL for RDDL
<timbl_> DanC suggested that thatcould be mapped to the RDF:
DC: Norm found fifteen RDDL docs inthe wild, and summarised their usage of RDDL (see above email)
DC: Looked at the BPEL NSdocument
... in particular forrddl:nature="http://www.w3.org/2001/XMLSchema"rddl:purpose="http://www.rddl.org/purposes#schema-validation"href="....xsd"
... I'd want this RDF:<bpel> rddl:schema-validation <...xsd> [in N3]
<timbl_> ______________<bpel> rddl:schemaValidation <http://.....bpel...xsd>.
<http://.....bpel...xsd> docRootEltName ( "http://www../" "XMLSchema"). # A pair, the XML element name
<bpel>rddl:schemaValidation <http://.....bpel...rrg>.
<http://.....bpel...rrg> docRootEltName ( "http://www.....rng..." "grammar"). # Apair
<http://.....bpel...html> rddl:normativeReference <http://www.w3.org/TR/HTML40>
_____________
DC: for all the above, assume rddl:bound to http://www.rddl.org/purposes#
...@prefix rddl: <http://www.rddl.org/purposes#>
<timbl_>( "http://www.....rng..." "grammar") is N3shorthand for[rdf:first "http://www.....rng..."; rdf:rest [rdf:first "grammar"; rdf:rest rdf:nil ]].
NW: What about adding a .rncreference, i.e. a relaxng compact syntax document
NM: Broken, in part because notparticipating in the self-describing web (no media type)
NW: Stipulate we have a mediatype
DC:<.....bpel...rnc>httpr2:content-type "text/rnc"
SW: Couldn't we use Schema ComponentDesignator instead of docRootEltName ?
<Norm> The media type for compactsyntax is application/relax-ng-compact-syntax
NM: SCDs is all about the bit afterthe '#', but have not yet any story about the bit before that
TBL: [starts down the LHS of SCDsrat-hole, pulls back]
NW: I have enough information toattempt the next step, i.e. to try converting my current draft tothe examples on the whiteboard
SW: Any other agreements?
DC: docRootEltName is a matter offact, but normative-reference is a matter of opinion
... I prefer the matters of fact
NM, HST, others: [back to the SCDs LHSrathole]
HST: The outstanding question here iswhat the best predicate for identifying things as W3C XML Schemas-- docRootEltName doesn't seem great
NM: And won't work if the xs:schemaelement isn't the root of a document. . .
<Noah> The back and forth betweenme and Dan suggests to me that what we need to solve the SchemaComponent Designator problem is in fact something very similar tonamespace description documents, but these would instead be"language" description documents, that would bring together thedeclarations for a root element, along with the constraints thatallow you to designate which documents are in your language. Ibelieve that, when schema is used, that language desc are resolved.
SW: TVR and DC are on point
DC: TBL has just published somethingrelevant, at [see below]
<timbl_>http://www.w3.org/2007/03/vision
DC: W3C just announced the newHTML/XHTML working groups
The above URI is TBL's background about this
<timbl_> This is linked fromhttp://www.w3.org/html/
<DanC_lap> also,http://esw.w3.org/topic/HTMLAsSheAreSpokehas a survey of tagsoup, beatiful soup, ...
DC: This document sets out threeoptions, similar to ones TV set out in a recent telcon:
... 1, Require XML at XHTML 1
... 2, Require XML, at XHTML 2
... 3, Incremental transition
... The WGs have been set up on the assumption that Incrementationtransition is the way to go
NM: Where does this doc't fit in
TV: As input ontagSoupIntegration-54
DC: What Incremental Transition meansto me is to look at cases until a pattern emerges
TV: In discussion to date, we havebrainstormed a lot of use cases
... I think the TAG can help by writing things down in one place,which hasn't been done
... for instance Ian Hickson's email on the problems withXHTML
... We should look in particular for the tension points
... for example the extensibility issue which is raised at the endof the 'vision' document
... I'm prepared to put my own opinions to one side and collectissues
TBL: Support that idea
... The TAG should take apart the idea of 'Incremental Transition'and look carefully at it
... What it means is instead of saying "messy browser reality" vs"pure XHTML2 coolness" -- you must choose
... We look at the differences which are actually out there betweentagsoup and well-formed XHTML
... and for each of them, we'll try to motivate change by analyzinghow the deviations harm the community
... W3C has commited to trying to produce a validator -- the TAGcan help spec. the behaviour of that validator
TV: [scribe missed]
... we know that if you're writing HTML, you can leave off endtags
... and browsers know how to cope
<timbl_> We should for each ofthe changes motivate them appropriately and with due priority.
<DanC_lap> (some people thinkquoting html inside RSS is a feature. I have a hard timeappreciating that position.)
TV: but if someone does this in thecontent of RSS and Atom, the well is poisoned, that is, to protectXML well-formedness the XML has to be quoted
<Zakim> DanC_lap, you wanted toask whether we actual have a useful connection to the RDDLcommunity
<Zakim> ht_mit, you wanted to askwhy anyone would ever serialise to thenon-XML syntax. . .
HST: Does this mean W3C willstandardise two different ways of serializing a DOM
DC: No, perhaps two syntaxes wouldhave been a better phrase
TBL: People have asked if we'reheading towards XML2
... that's one possible interpretation of the analysis of themotivation for the differences
TV: We've got a range of phenomena --close tags, quotes, etc.
... We have to distinguish which of these are really dangerous andwhich are not so bad
NM: What about new software -- whatadvice are we giving
... or new versions of old software
NM: I'm not sure about the idea ofdefending the idea of e.g. leaving out quotes in new software justto save a few bytes
... That's the wrong place to look for efficiency
TV: The point is that given that itworks == the browsers shows the right thing, it makessense forGoogle and Yahoo! to exploit the shortcuts
... When Google ships to mobile, we ship very carefully validHTML
TBL: Move that the TAG recommend thatbrowsers should change to Save As and View Source by default to docleanup first
<timbl_> TV seconded
TV: How much cleaned up?
<Rhys> Rhys notes that whenVolantis ships to mobile, which it does a lot, it ships markupcarefully matched to the device, warts and all
NW: The whole thing -- no choices,only full XML
DC: I opposed the motion because theTAG can't make this happen
TV: This is in the same spirit as thefinal observation in the 'vision' document about XML andextensibility
<timbl_> I wonder which of allthe things the TAG has recommended can be done by the TAGdirectly.
NM: We should put before thecommunity the stories that moving to XML really help with
<DanC_lap> I support fact-findingin the form of writing stories/use-cases in the direction of theview-source clean-up
<Zakim> DanC_lap, you wanted tocontrast the google homepage, where device-specific renditions arecost-effective, vs the state of kansas tax web sites, where it'sprobably not
NM: Helping people think about thesethings is as important as just giving them the answers
DC: The 'one web' principle is veryimportant to me
... My target audience is not Google, but the contractor who worksfor the state of Kansas tax office
... and he needs clearcut advice about theone thing he shoulddo.
TBL: There's also the long tail ofnovices who leave out the quotes because it's easier to write andread w/o them, and they have no need to
<DanC_lap> (if the TAG wants tohave a software-develoment management discussion about thevalidator, I'd appreciate that too.)
TBL: [Validates a document pulled offthe web, finds a spurious ';' between attributes in a start tag]
SW: [Validates a document pulled offthe web, finds unquoted background=#ffffff attribute]
TV: We should start building a listof incremental issues
<DanC_lap> TVR makes aninteresting observation, that tidy/tagsoup processes don't obeyf(x)=x for all well-formed x
NM: Will this be helpful, DanC?
DC: Can't tell
[break for lunch]