RDFa Task Force Meeting minutes for 2009-09-24

Minutes are:


text version below.

Cheers everyone




       [1] http://www.w3.org/

                         RDF in XHTML Task Force

24 Sep 2009



    Previous: [3]http://www.w3.org/2009/09/17-rdfa-minutes.html

       [3] http://www.w3.org/2009/09/17-rdfa-minutes.html

    See also: [4]IRC log

       [4] http://www.w3.org/2009/09/24-rdfa-irc


           Manu Sporny, Ivan Herman, Shane McCarron, Steven Pemberton,
           Ben Adida, Mark Birbeck

           Michael Hausenblas

           Ben Adida

           Manu Sporny, Ben Adida


      * [5]Topics
          1. [6]Action Items
          2. [7]ISSUE-239: errata text to clarify CURIE context
          3. [8]Adding Precision for DOM Level 2 and Infoset-based
             processing models
      * [9]Summary of Action Items

    Ben: See the xmlns:* post I made?

    Manu: Does it duplicate the same test we did 2 months ago?

    Ben: Maybe, but this works now (and it wasn't working before)

    Manu: Can we add this to the agenda:

      [10] http://lists.w3.org/Archives/Public/public-html/2009Sep/0959.html

Action Items

    <scribe> ACTION: Ben to update JS xmlns getter code on implementors'
    guide for xhtml mime type support [recorded in
    [11]http://www.w3.org/2009/09/17-rdfa-minutes.html#action02] [DONE]

      [11] http://www.w3.org/2009/09/17-rdfa-minutes.html#action02

ISSUE-239: errata text to clarify CURIE context

    <benadida> proposal text from Shane -->


    Ben: Jeni had some issues and Shane wrote some errata text to cover
    these issues.

    Manu: #6 should we say something about xmlns specifically? Or just
    refer to the XML Namespaces spec.

    Ivan: What about uppercase vs non-uppercase?

    Shane: We already have an errata item for that.

    <Zakim> markbirbeck, you wanted to say that Jeni also suggested that
    developers might assume that prefixes are already defined for
    'xmlns' and 'xml'.

    Mark: Jeni also raised the question if there should already be a
    prefix mapping for xmlns and xml
    ... It's worth considering.
    ... If you think of it in the case of namespaces, it's important.
    ... It's not a straighforward issue, but there is an argument that
    those two should be there by default.

    Shane: That would change the spec, don't know if we can do that in
    an errata
    ... For example, it would affect XMLLiterals.

    Mark: I don't think so - xmlns and xml are included by default in
    the XML pipeline.
    ... We say that it's initialized empty, but in a way it should be
    initialized with xmlns and xml.

    Shane: Ah, it's not legal to declare xmlns and xml.
    ... ah yes, catch-22.
    ... ok

    Ben: So, Mark - you are saying it should be initialized with xml and
    ... So, it's not just an errata - it could change the conformance.

    Mark: I don't know if it would change conformance criteria...

    Ben: I think this has to be a part of the 1.1 rev.

    Mark: Couldn't we do some of this in HTML+RDFa spec?

    Ben: We run the risk of duplicating rules, probably not a good idea.

    <ShaneM> Remember that there is room for an RDFa Syntax 1.0 Second
    Edition AND room for RDFa Syntax version 1.1

    Ivan: My impression is that HTML5 progress is slow, we might be able
    to get an RDFa 1.1 out before HTML5 goes to CR.
    ... Let's cross the bridge when we get there.

    Mark: Why not put this into RDFa 1.1 and publish that and reference
    that from HTML+RDFa?

    Ben: I think we are doing that, we're moving forward in parallel.

    Mark: Is there an RDFa 1.1 document right now? Why don't we start
    working on an RDFa 1.1 version.
    ... The problems we're solving for HTML5 should also go in RDFa 1.1

    Ben: So we're talking about a large encompassing document?

    Mark: So we integrate HTML+RDFa into RDFa Core 1.1
    ... and add some new things for RDFa Core 1.1

    Ben: Worried about how this might be perceived - should we start
    writing RDFa Core 1.1 while working on HTML+RDFa and doing errata
    for XHTML+RDFa?
    ... We should be very diligent in working with HTML WG.
    ... Point #5 - can you not use reserved words in @property and etc.

    Mark: We can loosen that restriction in RDFa Core 1.1

    Ben: This doesn't change what the spec says?

    Shane: Yes, it just gathers what the document already says.



    Ben: Anybody want more time to review this?

    <ShaneM> +1

    <ivan> +1

    <markbirbeck> +1

    +1 for passing this as an errata

    <Steven> +1

    Mark: So, this isn't a correction?

    Steven: No, it can be clarification as well

    <benadida> RESOLUTION ISSUE-239 is resolved as proposed by Shane

Adding Precision for DOM Level 2 and Infoset-based processing models

    Manu: convo with Henri, working to understand the xmlns DOM issue.
    ... actually a technical issue. implementation issue in infoset


      [14] http://lists.w3.org/Archives/Public/www-archive/2009Sep/0058.html

    Manu: working with Philip to integrate his tests.
    ... straight-forward, no need to discuss at length.
    ... Henri's issue: XHTML and HTML docs go through diff tool chains,
    no issue with XHTML docs in HTML5 toolchain.
    ... browsers are moving towards namespace-aware infoset models.
    ... with very specific APIs.
    ... but when we're parsing an HTML doc in non-XML mode, there is a
    ... with infoset-based parsers, what happens to attributes xmlns:*?
    ... infoset-based parsers do not have a DOM Level 1 interface,
    attributes on a node.
    ... with XHTML docs, straight-forward, just use namespace lookup
    ... but with HTML mode infoset doc, no namespaces.
    ... 'xmlns:foo' has been changed to some other string in the null
    ... Henri and Jonas say that 'xmlns:*' is destroyed.
    ... this is specified in the HTML5 spec.

    Steven: same bit of spec that i was complaining about?

    Manu: yes.

    Mark: just to be clear, this is something that HTML5 itself has

    Manu: because that's how the parsers work.
    ... they munge up the names.
    ... not something that was made up.
    ... makes sense that they did it this way, because HTML nothing to
    do with XML.

    Ben: but why munge the string?

    Manu: internal model is infoset based.
    ... we could say that this needs to be changed.
    ... then we have to make a case to vendors.

    Steven: so why does it work now?

    Manu: because they've layered the DOM layer on top of the
    infoset+internal model.
    ... but they like working with DOM Level 2 internally. Others like
    working with a clean Infoset-based API - like lxml and the html5lib

    <Zakim> ShaneM, you wanted to ask about infoset parsing

    Shane: appreciate that internally they're doing something to the
    string, but why do they or we care?
    ... this isn't exposed anywhere, is it?

    Manu: the problem is exposed in lxml parser and html5lib.

    Steven: browsers are intent on dealing with existing content. How
    could they possibly change the behavior of this?

    Manu: deal with existing content just fine.
    ... they don't have any namespaces.

    <Zakim> need, you wanted to talk about Infoset issues

    Manu: it's very important implementation guidance.
    ... Henri wants us to change the behavior of the coercion-to-infoset
    rules to actually create the namespaces.
    ... so that both in HTML and XML modes, that namespaces are defined.
    ... the solution is exactly what we want to see happen.
    ... Henri says that coercion-to-infoset should create namespaces.

    Ivan: is there any chance that this will happen?

    Manu: The mailing list discussions were misleading...

    Mark: not true, it's described *as if* it's a DOM.
    ... at moment independent of any structure.
    ... we have to be careful because there's a difference between
    writing "how to implement" and writing a spec that is general enough
    for implementation in the future.
    ... correct to ask "anything more than implementation guidance?"
    ... if we can smooth the path, definitely, but as Ivan says, can we
    really see this happening?
    ... alternatively, why can't we just use the munged name?
    ... should we cover this scenario, too?
    ... we shouldn't depend on the change to infoset.

    Ivan: do they want the rdfa spec written in terms of DOM?

    Manu: specifically yes, as function of DOM level 2, and as infoset

    Ivan: don't they have to expose in terms of DOM2 anyways?

    Manu: absolutely right, but the Infoset problem has nothing to do
    with DOM2 and what you can do in a browser.

    Ivan: why do *we* have to specify that?

    Manu:because it's not quite clear what you do in the case of an HTML
    document processed through an Infoset pipeline and resulting in a
    transformation from "xmlns:foo=[15]http://example.org/foo#" in the
    source document to an Infoset triple in the Infoset model
    (namespace, localname, value) -> (null, "xmlnsU00003Cfoo",
    "[16]http://example.org/foo#") -> all of our rules say something
    about "xmlns:" and nothing about "xmlnsU00003A" - so we need to
    clarify what we mean in this case, and point it out as a potential
    issue when creating an RDFa processor that utilizes an Infoset-based
    parser that does this to namespaces.

      [15] http://example.org/foo
      [16] http://example.org/foo

    <msporny> I really, really have to go be on the HTML WG call now...

    <ivan> ben, it is probably a good idea to write something about the
    usage of RDFa in (SKOS) vocabulary publication like the library of
    congress. I can add that later if you add the headline for it...

Summary of Action Items

    [DONE] ACTION: Ben to update JS xmlns getter code on implementors'
    guide for xhtml mime type support [recorded in

      [17] http://www.w3.org/2009/09/17-rdfa-minutes.html#action02

    [End of minutes]

     Minutes formatted by David Booth's [18]scribe.perl version 1.135
     ([19]CVS log)
     $Date: 2009/09/24 18:07:05 $

      [18] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
      [19] http://dev.w3.org/cvsweb/2002/scribe/


Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Thursday, 24 September 2009 18:10:31 UTC