See also: IRC log
John: producer may not understand all relative URI's
... if the consumer has these schema available he may be able to understand them
<johnarwe> if the producer is serializing content, some GEDs may be matching wildcards. if an element matches a wildcard to the producer, it cannot know if relative URIs are contained within the wildcard-matching elements.
Pratul: SMLIF is just a package and the spec should only talk about the content; everything else is out of scope ( such as how a consumer should process some information )
<johnarwe> the consumer on the other hand may have schemas available that allow it to recognize the elements (that the producer sees as wildcard matches)
<johnarwe> therefore the consumer would find an unmodified relative URI and it would not be correctly interpreted
Ginny: how does the producer know what needs to fix in the IF document ; (question relative to the anyURI contained by the IF document) ?
Pratul: do we have agreement on bug 5171 or we should move to thenext bug on the list ?
Sandy: as long as you take a set of documents and package them in the IF document, their base uri is lost
... how the consumer know how to unpack the documents ?
Kumar: in SQL implementations, data is not stored as file system
... so the unpacking of the documents is not an issue here
Pratul: discusses an IF sample
Kumar: there are 4 places from where you can get the document base URI
... the producer should make sure the document content is right so that the consumer can understand it
Sandy: there is some information available on base URI that is not in the IF ( for example on the file system if file location ); do you suggest to add this to the IF document ?
... but what if I already have an xml:base attribute ?
Pratul: if there is already one don't add another one
Kumar: document aliases in IF does not represent location, is just a way to identify a document
Sandy: a consumer should be able to consume IF documents produced by any producer
... so a consumer needs to have some information in the IF describing how to process the relative URI's
Ginny: can the consumer use the base uri defined for every IF document ?
Sandy: yes, but only when this information is available
Pratul: using base uri for every document is not seen as a requirement; the producer may choose to use it, if necessary
... if relative uri's are used in documents, the producer may probably want to use base uri to define the base in IF
Kumar: if the producer doesn't understand what is producing how can we assume that the consumer should understand this information?
... can we summarize what we found before we move to the next topic ?
John: we need first to understand if we have consenus on what we discussed as valid and supported scenarios
Kumar: will try summarize the discussion..
Pratul: one issue was that fragment only identifiers should not be fixed by applying absolute URI
... second issue : the value of the uri base in IF should be an absolute URI and only one base URI should be defined in an IF document
... how to preserve absolute URI when documents are packaged in IF , when the producer doesn't understand the URI?
Kumar: summarizes the issues on the board : 1. relative URI understood by the producer; 2. relative URI not understood by the producer
... question : should the producer fix relative URI's for the case the producer understand them ?
Ginny: expectation that producers will produce content they don't understand
Kumar: question : should the producer understand all the information in the IF document ?
... notes that implicit notion of structure in relative uri is lost when packaged in IF
Ginny: what is the next action ?
<scribe> ACTION: Kumar toreview 5171 with Sandy and come back with a proposal [recorded in http://www.w3.org/2007/10/16-sml-minutes.html#action01]
<trackbot-ng> Created ACTION-134 - Toreview 5171 with Sandy and come back with a proposal [on Kumar Pandit - due 2007-10-23].
Pratul: already discussed, make it dependent on 5171
Ginny: already depends on 5878, which is already resolved
Sandy: Ithink 5171 should be dependent on this one and not the other way around
Kumar: sure, let's do it as Sandy suggests
Resolution: make 5171 dependent on 5181
Pratul: the proposal is to move from xpointer(), Kumar proposes an alternate solution
MSM: this may contradict with the way the web architecture works
... understands the need for the proposal though
Pratul: what is the problem with this proposal ?
MSM: I think we'll get comments that we took over the task of defining the fragment identifier scheme
... suggest taking the task of asking for xpath1() scheme become a recomendation
... if we don't want to use xpointer() scheme because is not a rec, it's less work if we try to make this a scheme rather than try to use something else
Pratul: we can define our own scheme in the context of the SML spec; faster than to wait for somebody else to make something a rec
MSM; polite to communicate with the XPath language group and tell them we need this and ask them if they plan for having this as a rec; if not, we plan to address this within our group
Kumar: wonder why this has not been a rec yet and why we can succeed on this in a faster manner?
MSM: probably nobody needed our level of standardization
... we should ask other group to ake this a rec; if not we can mmake it part of our spec but probably part of a different document so that it can be reused
Pratul: nervous that this means slipping our own dates
... this is also not part of our charter
MSM: seems that how to deal with fragment identifier is part of our spec though
Kumar: a different document may pose a risk to our current dates, we are close to the LC milestone
John: for the record, Paul Groso is okay with us using xpath1() scheme
Ginny: we can define a scheme for xpointer() in our own spec - one option
John: wonders which of the proposed approaches is more likely to go smoothly
Pratul: as a compromise we can use the xpath1() scheme and then have an action to follow up with the wrc group to test if this may be an issue; if an issue, we can incorporate this in our scheme
Kumar: propose to define our own xpath1() scheme, choose a name for it and add it as a part of our spec
Ginny: we should also register this scheme
John: wonders what is the process for registering a scheme
Kumar: asks MSM if he is aware of the FixPointer activity and how this relates to the xpointer() scheme since the FixPointer group were originally part of the xpointer() group
MSM: irreconcilable differences between people who wanted reach support for references resulted in this new activity
... FixPointer is not actively proposed by anyone
Pratul: for this bug we have two options; 1. define our own scheme; 2. use xpath1() scheme
... Kumar is not comfortable with option2; he proposes option 1
John: we need to review the scheme registration process so that we know what can be done in terms of updating existing schemes so that we don't end up with issues
Kumar: agrees to review this process; due diligence on the procces
Resolution: use xpath1() scheme
Pratul: next question is whether we want to create a profile of the xpath1() scheme and use Kumar's proposal
... proposes to close 4636 and comment that the decision is to use xpath1()
Kumar: options 1. use xpath1() as is, 2. profile xpath1() 3. define our own scheme
Pratul: to summarize proposed approach: use xpath1() scheme and communicate with the wrc team to see if there are any issues with this approach; if any issues are identified then we go with defining our own scheme
<scribe> ACTION: Kumar to investigate if there any implemetation issues with supporting xpath1() scheme [recorded in http://www.w3.org/2007/10/16-sml-minutes.html#action02]
<trackbot-ng> Created ACTION-135 - Investigate if there any implemetation issues with supporting xpath1() scheme [on Kumar Pandit - due 2007-10-23].
Resolution: get back to this defect after Kumar and Pratul/John/MSM investigates issues with the proposed xpath1() scheme usage
Ginny: there is a document posted with the latest proposal
latest proposal http://lists.w3.org/Archives/Public/public-sml/2007Oct/0066.html
Ginny: the proposal is to specify that cycles are defined on elements; suggestion is to replace the existing document cycle as described in the spec
... acyclic can be specified on any complex type
... are annotations inherited ?
MSM: no, they are not
... only attributes and content model are inherited
... a way to make an annotation inherited, is to somehow add it to an attribute
Ginny: an element can have more children which are ref; this definition allow to define acyclic on specific child
... use sml:acyclic ref attribute to describe the elements on which acyclic should be enforced
Sandy: comments that acyclic can be inherited by making this a requirement in the SML spec; this is how we deal now with other SML inherited properties, sml:key
... the proposal is to make the acyclic properties inherited - should be applied on that type or inherited types
Jim: can this be implemented using schematron rules ?
MSM: only if you use XPath 2.0 and define a recursive function to keep deref'ing the references
Kumar: what if the acyclic is defined on the child instead of the parent and define cyclic any graph getting back to that element or the parent of that element
Sandy: it may not be necessarily on any ancestor
The discussion is around two options on how to define acyclic ; 1. define it at the ancestor level, which bounds it with a node type 2. define it at the reference level
the current proposal ( posted on the bug ) refers to option 1
sample for option 2:
<e n="left" sml:acyclic="./left"/>
<e n="right" sml:acyclic="./right"/>
sample for option 1:
Pratul: propose to resume the discussion at a later time
Jim: should we try to understand what options, 1 or 2, are considered at this time ?
Sandy: option 2 covers the case where the refs don't share the same parent type
break for lunch
Resolution: open action item against Ginny to update the proposal based on today's discussions
<scribe> ACTION: Ginny to update acyclic proposal to include the options discussed in the 10/16/07 f2f meeting [recorded in http://www.w3.org/2007/10/16-sml-minutes.html#action03]
<trackbot-ng> Sorry, couldn't find user - Ginny
<scribe> ACTION: Virginia update acyclic proposal to include the options discussed in the 10/16/07 f2f meeting [recorded in http://www.w3.org/2007/10/16-sml-minutes.html#action04]
<trackbot-ng> Created ACTION-136 - Update acyclic proposal to include the options discussed in the 10/16/07 f2f meeting [on Virginia Smith - due 2007-10-23].
Kirk: thinks there are usecases where we want to access xs:key and unique from sml:keyref
Kirk's proposal : http://lists.w3.org/Archives/Public/public-sml/2007Oct/0083.html
Kirk: investigated what needs to be added to the SML spec in order to allow such usecases
Kirk decsribes the proposal
Kirk to describe the proposal using a sample - on the board
Kirk: Kumar raised issues with overlapping symbol spaces for key and keyrefs between xsd and SML
... bug 5130 addresses constraint symbol space: 'clarify the extent of SML constraint symbol space '
<sml:keyref name="CoursesStudent" refer="xxx:StudentIDisKey" scope="tns:students">
Kirk: scope="tns:students" is the element in the current complex type where SML reference to Students is defined
... name=".." and refer=".." is standard
Pratul: asks for group opinion on this proposal
John: is key and keyref actually used in existing documents ?
MSM: there is a large collection of schemas over the net using key and keyref
Kumar: thisnks that the underlying need is to refer to existing data; you should not be required to update that data in order to make this happen
... agree with the motivation but feels that schema already provides this by using xs key and unique
... I think the initial intent was to have sml:key and sml:keyref defined as close as possible to the xsd counterparts; feels that this proposal moves away from the original intent
MSM: thinks that the arguments in favor is that offers clarity and simplicity; cons: overlapping symbol spaces, SML implementations will require to understand xsd key and keyref
Kirk: with the current spec content, sml keyref cannot use existing keys if defined using xml schema
Sandy: no strong opinion; feels like something nice to have and with no other consequences, simple to define and implement
Resolution: xml schema key and unique should be separated from the SML key; make this more explicit in the SML spec
5130 will be looked at later
Sandy: 4115 http://www.w3.org/Bugs/Public/show_bug.cgi?id=4995 seems related to this and is covered by the current bug discussion
Pratul: let's look at 4995 later
Ginny: the spec defines schematron query binding attribute to be some value that is not even defined in the schematron spec
... is it a good reason to restrict this query binding ?
Pratul: proposes to go with the schematron default query binding which is xslt; this should be the floor
... this statement should go in SML, not SMLIF
Resolution: consensus to fix it as mentioned above
Kumar: for a given target namespace you can't have two constraints with the same name
MSM: trying to understand what this means in conflicting schemas scenario
... I can't have these constrainsts with the same name and result in a valid model
Kumar: but we are going to handle the conflicting case in a separate proposal
Resolution: consensus on proposal, update to editorial
Kirk: requires to talk about this tomorrow as there is an ongoing off line discussion that may clarify this
Ginny: conformance section added to the IF document; want to have something similar in the SML spec
... something has been added to the SML spec but there are some changes reuiqred based on feedback
... the document is still changing; want to wait on this section until the document content is more stable
Resolution: agreement to wait on this
Kumar: doesn't understand the original comments
MSM: tries to remember what he meant
Sandy: comment 1 says that the quoted text is incorrect
<MSM> Proposal: as suggested by comment #2 on 4643, send communication to XML Schema suggesting that they may wish to impose constraints analogous to those of SML, in the interests of (a) alignment and (b) doing the right thing
<scribe> ACTION: Pratul write a proposal to to XML Schema group to address the issue decsribed in 4643 [recorded in http://www.w3.org/2007/10/16-sml-minutes.html#action05]
<trackbot-ng> Created ACTION-137 - Write a proposal to to XML Schema group to address the issue decsribed in 4643 [on Pratul Dublish - due 2007-10-23].
Pratul: resolve this wontfix or works for me
John: suggest to mark it wontfix
Ginny: 4643 blocks 5063
Pratul: mark this as editorial as it's covered by Sandy's reference proposal
Pratul: we had a similar discussion yesterday about what producers and consumers should be required
Ginny: not sure if we agreed on something
Pratul: we agreed that consumers MUST support uri scheme; producers are not required to support it
Ginny: we talked about this yesterday, related to bug 5121 but I don't think we reached agreement
... assumed that IF constraints both consumers and producers to support uri scheme
... would like to see this unchanged
MSM: is the requirement on a producer to support the uri scheme a testable requirement ?
Pratul: thinks it is
... the test would be that a consumer that understand only sml:uri can take a document and understand it; the doc can go through a round trip exchange and give the same results
Ginny: a level 1 conformant producer supports all IF scheme minus sml uri scheme
... level 2 consumers will also support sml uri scheme
Pratul: why do we need these 2 levels ?
Ginny: so that consumers that understand different schemes can claim conformance at some level
MSM: thinks is useful to use terms for documents to define level of conformance
Resolution: both consumers and producers are required to support sml uri scheme; a producer should be able to produce IF using sml uri scheme; define 2 levels of conformance for the IF documents; mark the defect editorial
Pratul: this seems to be done, covered by Sandy's reference proposal
MSM: what is the answer here ? 0 or more ?
Sandy: the answer is 0 or 1
Resolution: mark this editorial, covered by the ref proposal http://lists.w3.org/Archives/Public/public-sml/2007Sep/0268.html
Kirk: why are we talking about DTD's ?
MSM: this is DTD's for documents in the model we may want to inline
Kirk: but there is some statement, could not find now, that states XML Schema is the schema to use
MSM: possibility that somebody chooses to use entity references for special characters, there is nothing to prevent you using a DTD defining it and XML Schema for the language
... another posibility is that some people really want to use DTD and not XML Schema ( old documents, etc )
... to draft something as a proposal
Ginny: this defect is dependent on 4978
... propose to mark this dependant to 4978
MSM: remarks that it refers to a section that doesn't exist anymore
Ginny: I think it moved under section 6
Sandy: it is 6.1.4
Pratul: looks like a MUST
Resolution: resolve this to MUST and refer to whether to keep err in 4978; mark edittorial
MSM: this is the one reported by MSM
... does not recall the details
Sandy: feels that this is redundant
Resolution: completely remove this section
... remove bullet number 3 only
in addition, a similar section should go under the conformance criteria; on the sentence before the bullet change ref from 3.11.2 to 3.11
Pratul: we agreed to make the change in IF so that a new scheme defines if it is or not an IF scheme
Resolution: remove last sentence
move second sentence of the third paragraph to the addresing scheme definition
reword first sentence to say it is not an IF scheme because of the scheme's definition
<johnarwe> last sentence (of 3.4.2, to be removed) is: SML-IF Consumers MUST NOT interpret wsa:address content as inter-document references.
<johnarwe> sandy: do we need to deal with sml:uri for similar reasons in "SML-IF Consumers MUST interpret xsi:schemaLocation hints and sml:uri content used as SML reference schemes as inter-document references."
<johnarwe> proposal: remove "and sml:uri content used as SML reference schemes "
<johnarwe> resolution: consensus on proposed
<johnarwe> MSM raises 2 related questions
<johnarwe> 1. should we have said xsi:schemaLocation, since the xsi says instances only not xsds
<johnarwe> 2. do we need or want to distinguish between schemalocation in instances vs xsds
<johnarwe> update 4774 to handle #2 above
Sandy: propose to mark this as a dup of 5117
Resolution: agreed to close as dup of 5117
Pratul: I think this is done, covered by Sandy's ref proposal
Resolution: mark editorial, fix as per Sandy's proposal
Pratul: looks done
Kumar: so this should be dup of 4616
John: 4616 is not the right nb, is 4636
Resolution: dup of 4636
Jim: do we try to agree on object identity when using different schemes ?
Sandy: another case is when you have one scheme but multiple targets
Ginny: so when you get back 3 things you need to check if they represent the same object
Sandy: this is not about deref, it's about object validation
MSM: XPath can tell you the identity of object references but only if it refers to the same document
... need a way to identify that schemes are refering to the same document
... proposes to say that if two URI's are equal based on rfc spec, then they refer to the same document
John: proposes to use document aliases as part of the equality test
Jim: is the intend to say that if you are a conforming consumer than you have to be able to decide if two URI's are the same ?
MSM: no; we say that two expressions can evaluate to the same thing
... for documents we have the same story using URI
... for elements, we first establish they are in the same document; after that establish that the two XPath expressions evaluate to the same element
Jim: how do we test for compliant consumers based on these equivalence definitions ?
MSM: we need to specify when you are required to know two documents are the same
Jim: feels that there is disagreement at a fundamental level so doesn't want to stop here
Sandy: proposes to use this approach : if(cond1) then return equal; else if(cond2) then return not equal; else if (impl defined) else - if(true) - or -else return not equal-
... what we should say : if you can't say they are different then you can't say they are the same; this is what Sandy had proposed in bugzilla
Kumar: somebody should come with a proposal
Sandy: I already have a proposal, as decribed by the if(cond1) approach above
John: I don't think we can get over this until we specify what cond1 and cond2 are
Sandy: cond1=string comparison for URI ( assuming they have one)
... before we move to cond2, any suggestions on a better cond1 ?
MSM: rfc gives you several additional steps
Sandy: we use string comparison for IF so we should be consistent
MSM: okay, makes sense
Sandy: cond2=deep compare; (tree comparison, if anything in the tree is different than they are different)
... tricky if you return two elements that look the same; in infoset there is no way to say if they are different
... example on the tricky part : <p> <c/> <c/> </p>
Kumar: propose to make everything starting with cond2 implementation dependant since it may be expensive to do this deep compare
John: not wise since conformance is not meaningful
Kumar: then we'll have a spec with no implemetation
MSM: we aim for a meaningful spec